rfc2030.txt

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

   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. This allows clients configured in symmetric active
   (mode 1) to interoperate successfully, even if configured in possibly
   suboptimal ways. In multicast (unsolicited) mode, the VN field is set
   to 4, the Mode field is set to 5 (broadcast), and the Poll field set
   to the nearest integer base-2 logarithm of the poll interval.

      Note that it is highly desirable that, if a server supports
      multicast mode, it also supports unicast mode. This is so a
      potential multicast client can calculate the propagation delay
      using a client/server exchange prior to regular operation using
      only multicast mode. If the server supports anycast mode, then it
      must support unicast mode. There does not seem to be a great
      advantage to operate both multicast and anycast modes at the same
      time, although the protocol specification does not forbid it.

   In unicast and anycast modes, 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 multicast mode,
   the server sends broadcasts only if synchronized to a correctly



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


   operating reference clock.

   The remaining fields of the NTP header are set in the following way.
   Assuming the server is synchronized to a radio clock or other primary
   reference source and operating correctly, the LI field is set to 0
   and the Stratum field is set to 1 (primary server); 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 of Section 5 of
   this document.

   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 modem. In unicast
   and anycast modes, the Receive Timestamp and Transmit Timestamp
   fields are set to the time of day when the message is sent and 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 avoid replays. In multicast
   mode, the Originate Timestamp and Receive Timestamp fields are set to
   0 and the Transmit Timestamp field is set to the time of day when the
   message is sent. The following table summarizes these actions.

      Field Name              Unicast/Anycast          Multicast
                              Request    Reply
      ----------------------------------------------------------
      LI                      ignore     0 or 3        0 or 3
      VN                      1-4        copied from   4
                                         request
      Mode                    3          2 or 4        5
      Stratum                 ignore     1             1
      Poll                    ignore     copied from   log2 poll
                                         request       interval
      Precision               ignore     -log2 server  -log2 server
                                         significant   significant
                                         bits          bits
      Root Delay              ignore     0             0
      Root Dispersion         ignore     0             0
      Reference Identifier    ignore     source ident  source ident
      Reference Timestamp     ignore     time of last  time of last
                                         radio update  radio update



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


      Originate Timestamp     ignore     copied from   0
                                         transmit
                                         timestamp
      Receive Timestamp       ignore     time of day   0
      Transmit Timestamp      (see text) time of day   time of day
      Authenticator           optional   optional      optional

   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. Configuration and Management

   Initial setup for SNTP servers and clients can be done using a
   configuration file if a file system is available, or a serial port if
   not. It is intended that in-service management of NTP and SNTP
   Version 4 servers and clients be performed using SNMP and a suitable
   MIB to be published later. Ordinarily, SNTP servers and clients are
   expected to operate with little or no site-specific configuration,
   other than specifying the IP address and subnet mask or OSI NSAP
   address.

   Unicast clients must be provided with the designated server name or
   address. If a server name is used, the address of one of more DNS
   servers must be provided. Multicast servers and anycast clients  must
   be provided with the TTL and local broadcast or multicast group
   address. Anycast servers and multicast clients may be configured with
   a list of address-mask pairs for access control, so that only those
   clients or servers known to be trusted will be used. These servers
   and clients must implement the IGMP protocol and be provided with the
   local broadcast or multicast group address as well. The configuration
   data for cryptographic authentication is beyond the scope of this
   document.

   There are several scenarios which provide automatic server discovery
   and selection for SNTP clients with no pre-specified configuration,
   other than the IP address and subnet mask or OSI NSAP address. For a
   IP subnet or LAN segment including a fully functional NTP server, the
   clients can be configured for multicast mode using the local
   broadcast address. The same approach can be used with other servers
   using the multicast group address. In both cases, provision of an
   access control list is a good way to insure only trusted sources can
   be used to set the local clock.




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


   In another scenario suitable for an extended network with significant
   network propagation delays, clients can be configured for anycast
   mode, both upon initial startup and after some period when the
   currently selected unicast source has not been heard. Following the
   defined protocol, the client binds to the first reply heard and
   continues operation in unicast mode. In this mode the local clock can
   be automatically adjusted to compensate for the propagation delay.

   In still another scenario suitable for any network and where
   multicast service is not available, the DNS can be set up with a
   common CNAME, like time.domain.net, and a list of address records for
   NTP servers in the same domain. Upon resolving time.domain.net and
   obtaining the list, the client selects a server at random and begins
   operation in unicast mode with that server. Many variations on this
   theme are possible.

8. Acknowledgements

   Jeff Learman was helpful in developing the OSI model for this
   protocol. Ajit Thyagarajan provided valuable suggestions and
   corrections.

9. References

   [COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines
   for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.

   [DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
   USC Information Sciences Institute, September 1981.

   [DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
   RFC 1112, Stanford University, August 1989.

   [DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
   Specification", RFC 1883, Xerox and Ipsilon, January 1996.

   [DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless
   transport services on top of UDP - Version: 1", RFC 1240, Open
   Software Foundation, June 1991.

   [EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System
   Security Extensions", Work in Progress.

   [FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support
   basic communications applications", RFC 1698, Consultant,
   October 1994.





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


   [HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing
   Architecture", RFC 1884, Ipsilon and Xerox, January 1996.

   [ISO86] International Standards 8602 - Information Processing Systems
   - OSI: Connectionless Transport Protocol Specification. International
   Standards Organization, December 1986.

   [MIL92] Mills, D., "Network Time Protocol (Version 3) specification,
   implementation and analysis", RFC 1305, University of Delaware,
   March 1992.

   [PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting
   service", RFC 1546, Bolt Beranek Newman, November 1993.

   [POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
   USC Information Sciences Institute, August 1980.

   [POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
   USC Information Sciences Institute, May 1983.

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]



















Mills                        Informational                     [Page 18]