rfc1305.txt

RFC 的详细文档！

F.3.     Clock Modelling        81

F.4.     Development of a Composite Timescale   81

F.5.     Application to NTP     84

F.6.     Clock-Combining Procedure      84

G.       Appendix G. Computer Clock Modelling and Analysis      86

G.1.     Computer Clock Models  86

G.1.1.   The Fuzzball Clock Model       88

G.1.2.   The Unix Clock Model   89

G.2.     Mathematical Model of the NTP Logical Clock    91

G.3.     Parameter Management   93

G.4.     Adjusting VCO Gain (<$Ebold alpha>)    94

G.5.     Adjusting PLL Bandwidth (<$Ebold tau>) 94

G.6.     The NTP Clock Model    95

H.       Appendix H. Analysis of Errors and Correctness Principles

98

H.1.     Introduction   98

H.2.     Timestamp Errors       98

H.3.     Measurement Errors     100

H.4.     Network Errors 101

H.5.     Inherited Errors       102

H.6.     Correctness Principles 104

I.       Appendix I. Selected C-Language Program Listings       107

I.1.     Common Definitions and Variables       107

I.2.     Clock<196>Filter Algorithm     108

I.3.     Interval Intersection Algorithm        109

I.4.     Clock<196>Selection Algorithm  110

I.5.     Clock<196>Combining Procedure  111

I.6.     Subroutine to Compute Synchronization Distance 112

List of Figures

Figure 1. Implementation Model  6

Figure 2. Calculating Delay and Offset  25

Figure 3. Clock Registers       39

Figure 4. NTP Message Header    50

Figure 5. NTP Control Message Header    54

Figure 6. Status Word Formats   55

Figure 7. Authenticator Format  63

Figure 8. Comparison of UTC and NTP Timescales at Leap  79

Figure 9. Network Time Protocol 80

Figure 10. Hardware Clock Models        86

Figure 11. Clock Adjustment Process     90

Figure 12. NTP Phase-Lock Loop (PLL) Model      91

Figure 13. Timing Intervals     96

Figure 14. Measuring Delay and Offset   100

Figure 15. Error Accumulations  103

Figure 16. Confidence Intervals and Intersections       105

List of Tables

Table 1. System Variables       12

Table 2. Peer Variables 13

Table 3. Packet Variables       14

Table 4. Parameters     16

Table 5. Modes and Actions      22

Table 6. Clock Parameters       40

Table 7. Characteristics of Standard Oscillators        71

Table 8. Table of Leap-Second Insertions        77

Table 9. Notation Used in PLL Analysis  91

Table 10. PLL Parameters        91

Table 11. Notation Used in PLL Analysis 95

Table 12. Notation Used in Error Analysis       98

Introduction
This document constitutes a formal specification of the Network Time
Protocol (NTP) Version 3, which is used to synchronize timekeeping among
a set of distributed time servers and clients. It defines the
architectures, algorithms, entities and protocols used by NTP and is
intended primarily for implementors. A companion document [MIL91a]
summarizes the requirements, analytical models, algorithmic analysis and
performance under typical Internet conditions. Another document [MIL91b]
describes the NTP timescale and its relationship to other standard
timescales now in use. NTP was first described in RFC-958 [MIL85c], but
has since evolved in significant ways, culminating in the most recent
NTP Version 2 described in RFC-1119 [MIL89]. It is built on the Internet
Protocol (IP) [DAR81a] and User Datagram Protocol (UDP) [POS80], which
provide a connectionless transport mechanism; however, it is readily
adaptable to other protocol suites. NTP is evolved from the Time
Protocol [POS83b] and the ICMP Timestamp message [DAR81b], but is
specifically designed to maintain accuracy and robustness, even when
used over typical Internet paths involving multiple gateways, highly
dispersive delays and unreliable nets.

The service environment consists of the implementation model and service
model described in Section 2. The implementation model is based on a
multiple-process operating system architecture, although other
architectures could be used as well. The service model is based on a
returnable-time design which depends only on measured clock offsets, but
does not require reliable message delivery. The synchronization subnet
uses a self-organizing, hierarchical-master-slave configuration, with
synchronization paths determined by a minimum-weight spanning tree.
While multiple masters (primary servers) may exist, there is no
requirement for an election protocol.

NTP itself is described in Section 3. It provides the protocol
mechanisms to synchronize time in principle to precisions in the order
of nanoseconds while preserving a non-ambiguous date well into the next
century. The protocol includes provisions to specify the characteristics
and estimate the error of the local clock and the time server to which
it may be synchronized. It also includes provisions for operation with a
number of mutually suspicious, hierarchically distributed primary
reference sources such as radio-synchronized clocks.

Section 4 describes algorithms useful for deglitching and smoothing
clock-offset samples collected on a continuous basis. These algorithms
evolved from those suggested in [MIL85a], were refined as the results of
experiments described in [MIL85b] and further evolved under typical
operating conditions over the last three years. In addition, as the
result of experience in operating multiple-server subnets including
radio clocks at several sites in the U.S. and with clients in the U.S.
and Europe, reliable algorithms for selecting good clocks from a
population possibly including broken ones have been developed [DEC89],
[MIL91a] and are described in Section 4.

The accuracies achievable by NTP depend strongly on the precision of the
local-clock hardware and stringent control of device and process
latencies. Provisions must be included to adjust the software logical-
clock time and frequency in response to corrections produced by NTP.
Section 5 describes a local-clock design evolved from the Fuzzball
implementation described in [MIL83b] and [MIL88b]. This design includes
offset-slewing, frequency compensation and deglitching mechanisms
capable of accuracies in the order of a millisecond, even after extended
periods when synchronization to primary reference sources has been lost.

Details specific to NTP packet formats used with the Internet Protocol
(IP) and User Datagram Protocol (UDP) are presented in Appendix A, while
details of a suggested auxiliary NTP Control Message, which may be used
when comprehensive network-monitoring facilities are not available, are
presented in Appendix B. Appendix C contains specification and
implementation details of an optional authentication mechanism which can
be used to control access and prevent unauthorized data modification,
while Appendix D contains a listing of differences between Version 3 of
NTP and previous versions. Appendix E expands on issues involved with
precision timescales and calendar dating peculiar to computer networks
and NTP. Appendix F describes an optional algorithm to improve accuracy
by combining the time offsets of a number of clocks. Appendix G presents
a detailed mathematical model and analysis of the NTP local-clock
algorithms. Appendix H analyzes the sources and propagation of errors
and presents correctness principles relating to the time-transfer
service. Appendix I illustrates C-language code segments for the clock-
filter, clock-selection and related algorithms described in Section 4.

Related Technology

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 [POS83a], Time Protocol [POS83b], ICMP Timestamp
message [DAR81b] and IP Timestamp option [SU81]. Experimental results on
measured clock offsets and roundtrip delays in the Internet are
discussed in [MIL83a], [MIL85b], [COL88] and [MIL88a]. Other
synchronization algorithms are discussed in [LAM78], [GUS84], [HAL84],
[LUN84], [LAM85], [MAR85], [MIL85a], [MIL85b], [MIL85c], [GUS85b],
[SCH86], [TRI86], [RIC88], [MIL88a], [DEC89] and [MIL91a], while
protocols based on them are described in [MIL81a], [MIL81b], [MIL83b],
[GUS85a], [MIL85c], [TRI86], [MIL88a], [DEC89] and [MIL91a]. NTP uses
techniques evolved from them and both linear-systems and agreement
methodologies. Linear methods for digital telephone network
synchronization are summarized in [LIN80], while agreement methods for
clock synchronization are summarized in [LAM85].

The Digital Time Service (DTS) [DEC89] has many of the same service
objectives as NTP. The DTS design places heavy emphasis on configuration
management and correctness principles when operated in a managed LAN or
LAN-cluster environment, while NTP places heavy emphasis on the accuracy
and stability of the service operated in an unmanaged, global-internet
environment. In DTS a synchronization subnet consists of clerks,
servers, couriers and time providers. With respect to the NTP
nomenclature, a time provider is a primary reference source, a courier
is a secondary server intended to import time from one or more distant
primary servers for local redistribution and a server is intended to
provide time for possibly many end nodes or clerks. Unlike NTP, DTS does
not need or use mode or stratum information in clock selection and does
not include provisions to filter timing noise, select the most accurate
from a set of presumed correct clocks or compensate for inherent
frequency errors.

In fact, the latest revisions in NTP have adopted certain features of
DTS in order to support correctness principles. These include mechanisms
to bound the maximum errors inherent in the time-transfer procedures and
the use of a provably correct (subject to stated assumptions) mechanism
to reject inappropriate peers in the clock-selection procedures. These
features are described in Section 4 and Appendix H of this document.

The Fuzzball routing protocol [MIL83b], sometimes called Hellospeak,
incorporates time synchronization directly into the routing-protocol
design. One or more processes synchronize to an external reference
source, such as a radio clock or NTP daemon, and the routing algorithm
constructs a minimum-weight spanning tree rooted on these processes. The
clock offsets are then distributed along the arcs of the spanning tree
to all processes in the system and the various process clocks corrected
using the procedure described in Section 5 of this document. While it
can be seen that the design of Hellospeak strongly influenced the design
of NTP, Hellospeak itself is not an Internet protocol and is unsuited
for use outside its local-net environment.

The Unix 4.3bsd time daemon timed [GUS85a] uses a single master-time
daemon to measure offsets of a number of slave hosts and send periodic
corrections to them. In this model the master is determined using an
election algorithm [GUS85b] designed to avoid situations where either no
master is elected or more than one master is elected. The election
process requires a broadcast capability, which is not a ubiquitous
feature of the Internet. While this model has been extended to support
hierarchical configurations in which a slave on one network serves as a
master on the other [TRI86], the model requires handcrafted
configuration tables in order to establish the hierarchy and avoid
loops. In addition to the burdensome, but presumably infrequent,
overheads of the election process, the offset measurement/correction
process requires twice as many messages as NTP per update.

A scheme with features similar to NTP is described in [KOP87]. This
scheme is intended for multi-server LANs where each of a set of possibly
many time servers determines its local-time offset relative to each of
the other servers in the set using periodic timestamped messages, then
determines the local-clock correction using the Fault-Tolerant Average
(FTA) algorithm of [LUN84]. The FTA algorithm, which is useful where up
to k servers may be faulty, sorts the offsets, discards the k highest
and lowest ones and averages the rest. The scheme, as described in
[SCH86], is most suitable to LAN environments which support broadcast
and would result in unacceptable overhead in an internet environment. In
addition, for reasons given in Section 4 of this paper, the statistical
properties of the FTA algorithm are not likely to be optimal in an
internet environment with highly dispersive delays.

A good deal of research has gone into the issue of maintaining accurate