rfc958.txt

RFC 的详细文档！

Network Working Group                                         D.L. Mills
Request for Comments: 958                               M/A-COM Linkabit
                                                          September 1985

                      Network Time Protocol (NTP)


Status of this Memo

   This RFC suggests a proposed protocol for the ARPA-Internet
   community, and requests discussion and suggestions for improvements.
   Distribution of this memo is unlimited.

Table of Contents

   1.      Introduction
   2.      Service Model
   3.      Protocol Overview
   4.      State Variables and Formats
   5.      Protocol Operation
   5.1.    Protocol Modes
   5.2.    Message Processing
   5.3.    Network Considerations
   5.4.    Leap Seconds
   6.      References
   Appendix A. UDP Header Format
   Appendix B. NTP Data Format

1.  Introduction

   This document describes the Network Time Protocol (NTP), a protocol
   for synchronizing a set of network clocks using a set of distributed
   clients and servers.  NTP is built on the User Datagram Protocol
   (UDP) [13], which provides a connectionless transport mechanism.  It
   is evolved from the Time Protocol [7] and the ICMP Timestamp message
   [6] and is a suitable replacement for both.

   NTP provides the protocol mechanisms to synchronize time in principle
   to precisions in the order of nanoseconds while preserving a
   non-ambiguous date, at least for this century.  The protocol includes
   provisions to specify the precision and estimated error of the local
   clock and the characteristics of the reference clock to which it may
   be synchronized.  However, the protocol itself specifies only the
   data representation and message formats and does not specify the
   synchronizing algorithms or filtering mechanisms.

   Other mechanisms have been specified in the Internet protocol suite
   to record and transmit the time at which an event takes place,
   including the Daytime protocol [8] and IP Timestamp option [9].  The
   NTP is not meant to displace either of these mechanisms.  Additional
   information on network time synchronization can be found in the


Mills                                                           [Page 1]



RFC 958                                                        September
Network Time Protocol


   References at the end of this document.  An earlier synchronization
   protocol is discussed in [3] and synchronization algorithms in [2],
   [5], [10] and [12]. Experimental results on measured roundtrip delays
   and clock offsets in the Internet are discussed in [4] and [11].  A
   comprehensive mathematical treatment of clock synchronization can be
   found in [1].

2.  Service Model

   The intent of the service for which this protocol is designed is to
   connect a few primary reference clocks, synchronized by wire or radio
   to national standards, to centrally accessable resources such as
   gateways. These gateways would use NTP between them to cross-check
   the primary clocks and mitigate errors due to equipment or
   propagation failures. Some number of local-net hosts, serving as
   secondary reference clocks, would run NTP with one or more of these
   gateways.  In order to reduce the protocol overhead, these hosts
   would redistribute time to the remaining local-net hosts.  In the
   interest of reliability selected hosts might be equipped with less
   accurate but less expensive radio clocks and used for backup in case
   of failure of the primary and/or secondary clocks or communication
   paths between them.

   In the normal configuration a subnetwork of primary and secondary
   clocks will assume a hierarchical organization with the more accurate
   clocks near the top and the less accurate below.  NTP provides
   information that can be used to organize this hierarchy on the basis
   of precision or estimated error and even to serve as a rudimentary
   routing algorithm to organize the subnetwork itself.  However, the
   NTP protocol does not include a specification of the algorithms for
   doing this, which is left as a topic for further study.

3.  Protocol Overview

   There is no provision for peer discovery, acquisition, or
   authentication in NTP.  Data integrity is provided by the IP and UDP
   checksums.  No reachability, circuit-management, duplicate-detection
   or retransmission facilities are provided or necessary.  The service
   can operate in a symmetric mode, in which servers and clients are
   indistinguishable yet maintain a small amount of state information,
   or in an unsymmetric mode in which servers need maintain no client
   state other than that contained in the client request.  Moreover,
   only a single NTP message format is necessary, which simplifies
   implementation and can be used in a variety of solicited or
   unsolicited polling mechanisms.

   In what may be the most common (unsymmetric) mode a client sends an


Mills                                                           [Page 2]



RFC 958                                                        September
Network Time Protocol


   NTP message to one or more servers and processes the replies as
   received.  The server interchanges addresses and ports, fills in or
   overwrites certain fields in the message, recalculates the checksum
   and returns it immediately.  Information included in the NTP message
   allows each client/server peer to determine the timekeeping
   characteristics of its other peers, including the expected accuracies
   of their clocks. Using this information each peer is able to select
   the best time from possibly several other clocks, update the local
   clock and estimate its accuracy.

   It should be recognized that clock synchronization requires by its
   nature long periods and multiple comparisons in order to maintain
   accurate timekeeping.  While only a few comparisons are usually
   adequate to maintain local time to within a second, primarily to
   protect against broken hardware or synchronization failure, periods
   of hours or days and tens or hundreds of comparisons are required to
   maintain local time to within a few tens of milliseconds.
   Fortunately, the frequency of comparisons can be quite small and
   almost always non-intrusive to normal network operations.

4.  State Variables and Formats

   NTP timestamps are represented as a 64-bit fixed-point number, in
   seconds relative to 0000 UT on 1 January 1900.  The integer part is
   in the first 32 bits and the fraction part in the last 32 bits, as
   shown in the following diagram.

       0                   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 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Integer Part                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Fraction Part                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 low-order fraction bit increments at about
   0.2-nanosecond intervals, so a free-running one-millisecond clock
   will be in error only a small fraction of one part per million, or
   less than a second per year.

   In some cases a particular timestamp may not be available, such as
   when the protocol first starts up.  In these cases the 64-bit field
   is set to zero, indicating the value is invalid or undefined.



Mills                                                           [Page 3]



RFC 958                                                        September
Network Time Protocol


   Following is a description of the various data items used in the
   protocol.  Details of packet formats are presented in the Appendices.

   Leap Indicator

      This is a two-bit code warning of an impending leap-second to be
      inserted in the internationally coordinated Standard Time
      broadcasts.  A leap-second is occasionally added or subtracted
      from Standard Time, which is based on atomic clocks, to maintain
      agreement with Earth rotation.  When necessary, the corrections
      are notified in advance and executed at the end of the last day of
      the month in which notified, usually June or December.  When a
      correction is executed the first minute of the following day will
      have either 59 or 61 seconds.

   Status

      This is a six-bit code indicating the status of the local clock.
      Values are assigned to indicate whether it is operating correctly
      or in one of several error states.

   Reference Clock Type

      This is an eight-bit code identifying the type of reference clock
      used to set the local clock.  Values are assigned for primary
      clocks (locally synchronized to Standard Time), secondary clocks
      (remotely synchronized via various network protocols) and even
      eyeball-and-wristwatch.

   Precision

      This is a 16-bit signed integer indicating the precision of the
      local clock, in seconds to the nearest power of two.  For
      instance, a 60-Hz line-frequency clock would be assigned the value
      -6, while a 1000-Hz crystal clock would be assigned the value -10.

   Estimated Error

      This is a 32-bit fixed-point number indicating the estimated error
      of the local clock at the time last set.  The value is in seconds,
      with fraction point between bits 15 and 16, and is computed by the
      sender based on the reported error of the reference clock, the
      precision and drift rate of the local clock and the time the local
      clock was last set.  For statistical purposes this quantity can be
      assumed equal to the estimated or computed standard deviation, as
      described in [12].



Mills                                                           [Page 4]



RFC 958                                                        September
Network Time Protocol


   Estimated Drift Rate

      This is a 32-bit signed fixed-point number indicating the
      estimated drift rate of the local clock.  The value is
      dimensionless, with fraction point to the left of the high-order
      bit.  While for most purposes this value can be estimated based on
      the hardware characteristics, it is possible to compute it quite
      accurately, as described in [12].

   Reference Clock Identifier

      This is a 32-bit code identifying the particular reference clock.
      The interpretation of its value depends on value of Reference
      Clock Type.  In the case of a primary clock locally synchronized
      to Standard Time (type 1), the value is an ASCII string
      identifying the clock.  In the case of a secondary clock remotely
      synchronized to an Internet host via NTP (type 2), the value is
      the 32-bit Internet address of that host.  In other cases the
      value is undefined.

   Reference Timestamp

      This is a 64-bit timestamp established by the server or client
      host as the timestamp (presumably obtained from a reference clock)
      most recently used to update the local clock.  If the local clock
      has never been synchronized, the value is zero.

   Originate Timestamp

      This is a 64-bit timestamp established by the client host and
      specifying the local time at which the request departed for the
      service host.  It will always have a nonzero value.