RFC 958 (rfc958) - Page 2 of 14
Network Time Protocol (NTP)
Alternative Format: Original Text Document
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