RFC 958 (rfc958) - Page 2 of 14

Network Time Protocol (NTP)

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