rfc1059.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/5 页
TXT
1,404 行
3 December 1973 10 June 1981
4 December 1974 11 June 1982
5 December 1975 12 June 1983
6 December 1976 13 June 1985
7 December 1977 14 December 1987
Table 2.1. Dates of Leap-Second Insertion
Like UTC, NTP operates with an abstract oscillator synchronized in
frequency to the TA time scale. At 0000 hours on 1 January 1972 the
NTP time scale was set to 2,272,060,800, representing the number of
TA seconds since 0000 hours on 1 January 1900. The insertion of leap
seconds in UTC does not affect the oscillator itself, only the
translation between TA and UTC, or conventional civil time. However,
since the only institutional memory assumed by NTP is the UTC radio
broadcast service, the NTP time scale is in effect reset to UTC as
each offset estimate is computed. When a leap second is inserted in
UTC and subsequently in NTP, knowledge of all previous leap seconds
is lost. Thus, if a clock synchronized to NTP in early 1988 was used
to establish the time of an event that occured in early 1972, it
would be fourteen seconds early.
When NTP is used to measure intervals between events that straddle a
leap second, special considerations apply. When it is necessary to
determine the elapsed time between events, such as the half life of a
proton, NTP timestamps of these events can be used directly. When it
is necessary to establish the order of events relative to UTC, such
as the order of funds transfers, NTP timestamps can also be used
directly; however, if it is necessary to establish the elapsed time
between events relative to UTC, such as the intervals between
payments on a mortgage, NTP timestamps must be converted to UTC using
the above table and its successors.
The current formats used by NBS radio broadcast services [2] do not
include provisions for advance notice of leap seconds, so this
information must be determined from other sources. NTP includes
provisions to distribute advance warnings of leap seconds using the
Leap Indicator bits described in Section 3. The protocol is designed
so that these bits can be set manually at the primary clocks and then
automatically distributed throughout the system for delivery to all
logical clocks and then effected as described in Section 5.
Mills [Page 11]
RFC 1059 Network Time Protocol July 1988
3. Network Time Protocol
This section consists of a formal definition of the Network Time
Protocol, including its data formats, entities, state variables,
events and event-processing procedures. The specification model is
based on the implementation model illustrated in Figure 2.1, but it
is not intended that this model is the only one upon which a
specification can be based. In particular, the specification is
intended to illustrate and clarify the intrinsic operations of NTP
and serve as a foundation for a more rigorous, comprehensive and
verifiable specification.
3.1. Data Formats
All mathematical operations expressed or implied herein are in
two's-complement arithmetic. Data are specified as integer or
fixed-point quantities. Since various implementations would be
expected to scale externally derived quantities for internal use,
neither the precision nor decimal-point placement for fixed-point
quantities is specified. Unless specified otherwise, all quantities
are unsigned and may occupy the full field width, if designated, with
an implied zero preceding the most significant (leftmost) bit.
Hardware and software packages designed to work with signed
quantities will thus yield surprising results when the most
significant (sign) bit is set. It is suggested that externally
derived, unsigned fixed-point quantities such as timestamps be
shifted right one bit for internal use, since the precision
represented by the full field width is seldom justified.
Since NTP timestamps are cherished data and, in fact, represent the
main product of the protocol, a special timestamp format has been
established. NTP timestamps are represented as a 64-bit unsigned
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 precision of this representation is about 0.2
Mills [Page 12]
RFC 1059 Network Time Protocol July 1988
nanosecond, which should be adequate for even the most exotic
requirements.
Timestamps are determined by copying the current value of the logical
clock to a timestamp variable when some significant event, such as
the arrival of a message, occurs. In order to maintain the highest
accuracy, it is important that this be done as close to the hardware
or software driver associated with the event as possible. In
particular, departure timestamps should be redetermined for each
link-level retransmission. In some cases a particular timestamp may
not be available, such as when the host is rebooted or the protocol
first starts up. In these cases the 64-bit field is set to zero,
indicating the value is invalid or undefined.
Note that since some time in 1968 the most significant bit (bit 0 of
the Integer Part) has been set and that the 64-bit field will
overflow some time in 2036. Should NTP be in use in 2036, some
external means will be necessary to qualify time relative to 1900 and
time relative to 2036 (and other multiples of 136 years).
Timestamped data requiring such qualification will be so precious
that appropriate means should be readily available. There will exist
an 0.2-nanosecond interval, henceforth ignored, every 136 years when
the 64-bit field will be zero and thus considered invalid.
3.2. State Variables and Parameters
Following is a tabular summary of the various state variables and
parameters used by the protocol. They are separated into classes of
system variables, which relate to the operating system environment
and logical clock mechanism; peer variables, which are specific to
each peer operating in symmetric mode or client mode; packet
variables, which represent the contents of the NTP message; and
parameters, which are fixed in all implementations of the current
version. For each class the description of the variable is followed
by its name and the procedure or value which controls it. Note that
variables are in lower case, while parameters are in upper case.
Mills [Page 13]
RFC 1059 Network Time Protocol July 1988
System Variables Name Control
-------------------------------------------------------
Logical Clock sys.clock update
Clock Source sys.peer selection
algorithm
Leap Indicator sys.leap update
Stratum sys.stratum update
Precision sys.precision system
Synchronizing Distance sys.distance update
Estimated Drift Rate sys.drift system
Reference Clock Identifier sys.refid update
Reference Timestamp sys.reftime update
Table 3.1. System Variables
Peer Variables Name Control
-------------------------------------------------------
Peer Address peer.srcadr system
Peer Port peer.srcport system
Local Address peer.dstadr system
Local Port peer.dstport system
Peer State peer.state receive,
transmit
Reachability Register peer.reach receive,
transmit
Peer Timer peer.timer system
Timer Threshold peer.threshold system
Leap Indicator peer.leap receive
Stratum peer.stratum receive
Peer Poll Interval peer.ppoll receive
Host Poll Interval peer.hpoll receive,
transmit
Precision peer.precision receive
Synchronizing Distance peer.distance receive
Estimated Drift Rate peer.drift receive
Reference Clock Identifier peer.refid receive
Reference Timestamp peer.reftime receive
Originate Timestamp peer.org receive
Receive Timestamp peer.rec receive
Filter Register peer.filter filter
algorithm
Delay Estimate peer.delay filter
algorithm
Offset Estimate peer.offset filter
algorithm
Dispersion Estimate peer.dispersion filter
Table 3.2. Peer Variables
Mills [Page 14]
RFC 1059 Network Time Protocol July 1988
Packet Variables Name Control
-------------------------------------------------------
Peer Address pkt.srcadr transmit
Peer Port pkt.srcport transmit
Local Address pkt.dstadr transmit
Local Port pkt.dstport transmit
Leap Indicator pkt.leap transmit
Version Number pkt.version transmit
Stratum pkt.stratum transmit
Poll pkt.poll transmit
Precision pkt.precision transmit
Synchronizing Distance pkt.distance transmit
Estimated Drift Rate pkt.drift transmit
Reference Clock Identifier pkt.refid transmit
Reference Timestamp pkt.reftime transmit
Originate Timestamp pkt.org transmit
Receive Timestamp pkt.rec transmit
Transmit Timestamp pkt.xmt transmit
Table 3.3. Packet Variables
Parameters Name Value
-------------------------------------------------------
NTP Version NTP.VERSION 1
NTP Port NTP.PORT 123
Minimum Polling Interval NTP.MINPOLL 6 (64 sec)
Maximum Polling Interval NTP.MAXPOLL 10 (1024
sec)
Maximum Dispersion NTP.MAXDISP 65535 ms
Reachability Register Size PEER.WINDOW 8
Shift Register Size PEER.SHIFT 4/8
Dispersion Threshold PEER.THRESHOLD 500 ms
Filter Weight PEER.FILTER .5
Select Weight PEER.SELECT .75
Table 3.4. Parameters
Following is a description of the various variables used in the
protocol. Additional details on formats and use are presented in
later sections and appendices.
3.2.1. Common Variables
The following variables are common to the system, peer and packet
classes.
Peer Address (peer.srcadr, pkt.srcadr) Peer Port (peer.srcport,
pkt.srcport)
Mills [Page 15]
RFC 1059 Network Time Protocol July 1988
These are the 32-bit Internet address and 16-bit port number of
the remote host.
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?