1. Introduction

5927 users shared this document! click

1. 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 configura-
tion, 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 RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 1 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. 1.1. 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 RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 2 time-transfer procedures and the use of a provably correct (subject to stated assumptions) mecha-
nism 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 synchro-
nization 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 time in a community where
some clocks cannot be trusted. A truechimer is a clock that maintains timekeeping accuracy to a
previously published (and trusted) standard, while a falseticker is a clock that does not. Determining
whether a particular clock is a truechimer or falseticker is an interesting abstract problem which can
be attacked using agreement methods summarized in [LAM85] and [SRI87]. A convergence function operates upon the offsets between the clocks in a system to increase the
accuracy by reducing or eliminating errors caused by falsetickers. There are two classes of
convergence functions, those involving interactive-convergence algorithms and those involving
interactive-consistency algorithms. Interactive-convergence algorithms use statistical clustering RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 3 techniques such as the fault-tolerant average algorithm of [HAL84], the CNV algorithm of
[LUN84], the majority-subset algorithm of [MIL85a], the non-Byzantine algorithm of [RIC88], the
egocentric algorithm of [SCH86], the intersection algorithm of [MAR85] and [DEC89] and the
algorithms in Section 4 of this document. Interactive-consistency algorithms are designed to detect faulty clock processes which might
indicate grossly inconsistent offsets in successive readings or to different readers. These algorithms
use an agreement protocol involving successive rounds of readings, possibly relayed and possibly
augmented by digital signatures. Examples include the fireworks algorithm of [HAL84] and the
optimum algorithm of [SRI87]. However, these algorithms require large numbers of messages,
especially when large numbers of clocks are involved, and are designed to detect faults that have
rarely been found in the Internet experience. For these reasons they are not considered further in
this document. In practice it is not possible to determine the truechimers from the falsetickers on other than a
statistical basis, especially with hierarchical configurations and a statistically noisy Internet. While
it is possible to bound the maximum errors in the time-transfer procedures, assuming sufficiently
generous tolerances are adopted for the hardware components, this generally results in rather poor
accuracies and stabilities. The approach taken in the NTP design and its predecessors involves
mutually coupled oscillators and maximum-likelihood estimation and clock-selection procedures,
together with a design that allows provable assertions on error bounds to be made relative to stated
assumptions on the correctness of the primary reference sources. From the analytical point of view,
the system of distributed NTP peers operates as a set of coupled phase-locked oscillators, with the
update algorithm functioning as a phase detector and the local clock as a disciplined oscillator, but
with deterministic error bounds calculated at each step in the time-transfer process. The particular choice of offset measurement and computation procedure described in Section 3 is
a variant of the returnable-time system used in some digital telephone networks [LIN80]. The clock
filter and selection algorithms are designed so that the clock synchronization subnet self-organizes
into a hierarchical-master-slave configuration [MIT80]. With respect to timekeeping accuracy and
stability, the similarity of NTP to digital telephone systems is not accidental, since systems like this
have been studied extensively [LIN80], [BRA80]. What makes the NTP model unique is the
adaptive configuration, polling, filtering, selection and correctness mechanisms which tailor the
dynamics of the system to fit the ubiquitous Internet environment. 2. System Architecture In the NTP model a number of primary reference sources, synchronized by wire or radio to national
standards, are connected to widely accessible resources, such as backbone gateways, and operated
as primary time servers. The purpose of NTP is to convey timekeeping information from these
servers to other time servers via the Internet and also to cross-check clocks and mitigate errors due
to equipment or propagation failures. Some number of local-net hosts or gateways, acting as
secondary time servers, run NTP with one or more of the primary servers. In order to reduce the
protocol overhead, the secondary servers distribute time via NTP to the remaining local-net hosts.
In the interest of reliability, selected hosts can be equipped with less accurate but less expensive RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 4 radio clocks and used for backup in case of failure of the primary and/or secondary servers or
communication paths between them. Throughout this document a standard nomenclature has been adopted: the stability of a clock is how
well it can maintain a constant frequency, the accuracy is how well its frequency and time compare
with national standards and the precision is how precisely these quantities can be maintained within
a particular timekeeping system. Unless indicated otherwise, the offset of two clocks is the time
difference between them, while the skew is the frequency difference (first derivative of offset with
time) between them. Real clocks exhibit some variation in skew (second derivative of offset with
time), which is called drift; however, in this version of the specification the drift is assumed zero. NTP is designed to produce three products: clock offset, roundtrip delay and dispersion, all of which
are relative to a selected reference clock. Clock offset represents the amount to adjust the local clock
to bring it into correspondence with the reference clock. Roundtrip delay provides the capability to
launch a message to arrive at the reference clock at a specified time. Dispersion represents the
maximum error of the local clock relative to the reference clock. Since most host time servers will
synchronize via another peer time server, there are two components in each of these three products,
those determined by the peer relative to the primary reference source of standard time and those
measured by the host relative to the peer. Each of these components are maintained separately in
the protocol in order to facilitate error control and management of the subnet itself. They provide
not only precision measurements of offset and delay, but also definitive maximum error bounds, so
that the user interface can determine not only the time, but the quality of the time as well. There is no provision for peer discovery or virtual-circuit management in NTP. Data integrity is
provided by the IP and UDP checksums. No flow-control or retransmission facilities are provided
or necessary. Duplicate detection is inherent in the processing algorithms. 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 client/server mode, in which servers need maintain no state other than
that contained in the client request. A lightweight association-management capability, including
dynamic reachability and variable poll-rate mechanisms, is included only to manage the state
information and reduce resource requirements. Since only a single NTP message format is used,
the protocol is easily implemented and can be used in a variety of solicited or unsolicited polling
mechanisms. 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 measurements are usually
adequate to reliably determine local time to within a second or so, periods of many hours and dozens
of measurements are required to resolve oscillator skew and maintain local time to the order of a
millisecond. Thus, the accuracy achieved is directly dependent on the time taken to achieve it.
Fortunately, the frequency of measurements can be quite low and almost always non-intrusive to
normal net operations. RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 5 2.1. Implementation Model In what may be the most common client/server model a client sends an NTP message to one or more
servers and processes the replies as received. The server interchanges addresses and ports, over-
writes certain fields in the message, recalculates the checksum and returns the message immediately.
Information included in the NTP message allows the client to determine the server time with respect
to local time and adjust the local clock accordingly. In addition, the message includes information
to calculate the expected timekeeping accuracy and reliability, as well as select the best from
possibly several servers. While the client/server model may suffice for use on local nets involving a public server and perhaps
many workstation clients, the full generality of NTP requires distributed participation of a number
of client/servers or peers arranged in a dynamically reconfigurable, hierarchically distributed
configuration. It also requires sophisticated algorithms for association management, data manipu-
lation and local-clock control. Throughout the remainder of this document the term host refers to
an instantiation of the protocol on a local processor, while the term peer refers to the instantiation
of the protocol on a remote processor connected by a network path. Figure 1 shows an implementation model for a host including three processes sharing a partitioned
data base, with a partition dedicated to each peer, and interconnected by a message-passing system.
The transmit process, driven by independent timers for each peer, collects information in the data
base and sends NTP messages to the peers. Each message contains the local timestamp when the
message is sent, together with previously received timestamps and other information necessary to
determine the hierarchy and manage the association. The message transmission rate is determined
by the accuracy required of the local clock, as well as the accuracies of its peers. The receive process receives NTP messages and perhaps messages in other protocols, as well as
information from directly connected radio clocks. When an NTP message is received, the offset
between the peer clock and the local clock is computed and incorporated into the data base along Update Procedure Receive Process Local Clock Process Transmit Process Network Figure 1. Implementation Model RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 6 with other information useful for error determination and peer selection. A filtering algorithm
described in Section 4 improves the accuracy by discarding inferior data. The update procedure is initiated upon receipt of a message and at other times. It processes the offset
data from each peer and selects the best one using the algorithms of Section 4. This may involve
many observations of a few peers or a few observations of many peers, depending on the accuracies
required. The local-clock process operates upon the offset data produced by the update procedure and adjusts
the phase and frequency of the local clock using the mechanisms described in Section 5. This may
result in either a step-change or a gradual phase adjustment of the local clock to reduce the offset
to zero. The local clock provides a stable source of time information to other users of the system
and for subsequent reference by NTP itself. 2.2. Network Configurations The synchronization subnet is a connected network of primary and secondary time servers, clients
and interconnecting transmission paths. A primary time server is directly synchronized to a primary
reference source, usually a radio clock. A secondary time server derives synchronization, possibly
via other secondary servers, from a primary server over network paths possibly shared with other
services. Under normal circumstances it is intended that the synchronization subnet of primary and
secondary servers assumes a hierarchical-master-slave configuration with the primary servers at the
root and secondary servers of decreasing accuracy at successive levels toward the leaves. Following conventions established by the telephone industry [BEL86], the accuracy of each server
is defined by a number called the stratum, with the topmost level (primary servers) assigned as one
and each level downwards (secondary servers) in the hierarchy assigned as one greater than the
preceding level. With current technology and available radio clocks, single-sample accuracies in
the order of a millisecond can be achieved at the network interface of a primary server. Accuracies
of this order require special care in the design and implementation of the operating system and the
local-clock mechanism, such as described in Section 5. As the stratum increases from one, the single-sample accuracies achievable will degrade depending
on the network paths and local-clock stabilities. In order to avoid the tedious calculations [BRA80]
necessary to estimate errors in each specific configuration, it is useful to assume the mean
measurement errors accumulate approximately in proportion to the measured delay and dispersion
relative to the root of the synchronization subnet. Appendix H contains an analysis of errors,
including a derivation of maximum error as a function of delay and dispersion, where the latter
quantity depends on the precision of the timekeeping system, frequency tolerance of the local clock
and various residuals. Assuming the primary servers are synchronized to standard time within
known accuracies, this provides a reliable, determistic specification on timekeeping accuracies
throughout the synchronization subnet. Again drawing from the experience of the telephone industry, which learned such lessons at
considerable cost [ABA89], the synchronization subnet topology should be organized to produce
the highest accuracy, but must never be allowed to form a loop. An additional factor is that each RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 7 increment in stratum involves a potentially unreliable time server which introduces additional
measurement errors. The selection algorithm used in NTP uses a variant of the Bellman-Ford
distributed routing algorithm [37] to compute the minimum-weight spanning trees rooted on the
primary servers. The distance metric used by the algorithm consists of the (scaled) stratum plus the
synchronization distance, which itself consists of the dispersion plus one-half the absolute delay.
Thus, the synchronization path will always take the minimum number of servers to the root, with
ties resolved on the basis of maximum error. As a result of this design, the subnet reconfigures automatically in a hierarchical-master-slave
configuration to produce the most accurate and reliable time, even when one or more primary or
secondary servers or the network paths between them fail. This includes the case where all normal
primary servers (e.g., highly accurate WWVB radio clock operating at the lowest synchronization
distances) on a possibly partitioned subnet fail, but one or more backup primary servers (e.g., less
accurate WWV radio clock operating at higher synchronization distances) continue operation.
However, should all primary servers throughout the subnet fail, the remaining secondary servers
will synchronize among themselves while distances ratchet upwards to a preselected maximum
“infinity” due to the well-known properties of the Bellman-Ford algorithm. Upon reaching the
maximum on all paths, a server will drop off the subnet and free-run using its last determined time
and frequency. Since these computations are expected to be very precise, especially in frequency,
even extended outage periods can result in timekeeping errors not greater than a few milliseconds
per day with appropriately stabilized oscillators (see Section 5). In the case of multiple primary servers, the spanning-tree computation will usually select the server
at minimum synchronization distance. However, when these servers are at approximately the same
distance, the computation may result in random selections among them as the result of normal
dispersive delays. Ordinarily, this does not degrade accuracy as long as any discrepancy between
the primary servers is small compared to the synchronization distance. If not, the filter and selection
algorithms will select the best of the available servers and cast out outlyers as intended. 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 is based on the
implementation model illustrated in Figure 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, as well as to 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, fixed-point
arithmetic. Data are specified as integer or fixed-point quantities, with bits numbered in big-endian
fashion from zero starting at the left, or high-order, position. Since various implementations may
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 RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 8 may occupy the full field width with an implied zero preceding bit zero. 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 0 h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. 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 200 picoseconds, which should be adequate for even the most exotic
requirements. Timestamps are determined by copying the current value of the local clock to a timestamp 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 200-picosecond 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 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 local-clock mechanism; peer variables, which represent the state of the protocol machine
specific to each peer; packet variables, which represent the contents of the NTP message; and
parameters, which represent fixed configuration constants for 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.
Additional details on formats and use are presented in later sections and Appendices. 3.2.1. Common Variables The following variables are common to two or more of the system, peer and packet classes.
Additional variables are specific to the optional authentication mechanism as described in Appendix RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 9 C. When necessary to distinguish between common variables of the same name, the variable
identifier will be used. Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port (peer.peerport, pkt.peerport): These are the 32-bit Internet address and 16-bit port number of the peer. Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport, pkt.hostport): These are the 32-bit Internet address and 16-bit port number of the host. They are included among the state
variables to support multi-homing. Leap Indicator (sys.leap, peer.leap, pkt.leap): This is a two-bit code warning of an impending leap second to be inserted in the NTP timescale. The bits are set before 23:59 on the day of insertion
and reset after 00:00 on the following day. This causes the number of seconds (rollover interval)
in the day of insertion to be increased or decreased by one. In the case of primary servers the
bits are set by operator intervention, while in the case of secondary servers the bits are set by
the protocol. The two bits, bit 0 and bit 1, respectively, are coded as follows: 00 no warning 01 last minute has 61 seconds 10 last minute has 59 seconds 11 alarm condition (clock not synchronized) In all except the alarm condition (11 2 ), NTP itself does nothing with these bits, except pass them on to the time-conversion routines that are not part of NTP. The alarm condition occurs when,
for whatever reason, the local clock is not synchronized, such as when first coming up or after
an extended period when no primary reference source is available. Mode (peer.mode, pkt.mode): This is an integer indicating the association mode, with values coded as follows: 0 unspecified 1 symmetric active 2 symmetric passive 3 client 4 server 5 broadcast 6 reserved for NTP control messages 7 reserved for private use Stratum (sys.stratum, peer.stratum, pkt.stratum): This is an integer indicating the stratum of the local clock, with values defined as follows: 0 unspecified 1 primary reference (e.g., calibrated atomic clock, radio clock) 2-255 secondary reference (via NTP) RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 10 For comparison purposes a value of zero is considered greater than any other value. Note that
the maximum value of the integer encoded as a packet variable is limited by the parameter
NTP.MAXSTRATUM. Poll Interval (sys.poll, peer.hostpoll, peer.peerpoll, pkt.poll): This is a signed integer indicating the minimum interval between transmitted messages, in seconds as a power of two. For instance, a
value of six indicates a minimum interval of 64 seconds. Precision (sys.precision, peer.precision, pkt.precision): This is a signed integer indicating the precision of the various clocks, in seconds to the nearest power of two. The value must be
rounded to the next larger power of two; for instance, a 50-Hz (20 ms) or 60-Hz (16.67 ms)
power-frequency clock would be assigned the value -5 (31.25 ms), while a 1000-Hz (1 ms)
crystal-controlled clock would be assigned the value -9 (1.95 ms). Root Delay (sys.rootdelay, peer.rootdelay, pkt.rootdelay): This is a signed fixed-point number indicating the total roundtrip delay to the primary reference source at the root of the synchroni-
zation subnet, in seconds. Note that this variable can take on both positive and negative values,
depending on clock precision and skew. Root Dispersion (sys.rootdispersion, peer.rootdispersion, pkt.rootdispersion): This is a signed fixed-point number indicating the maximum error relative to the primary reference source at the
root of the synchronization subnet, in seconds. Only positive values greater than zero are
possible. Reference Clock Identifier (sys.refid, peer.refid, pkt.refid): This is a 32-bit code identifying the particular reference clock. In the case of stratum 0 (unspecified) or stratum 1 (primary reference
source), this is a four-octet, left-justified, zero-padded ASCII string, for example (see Appendix
A for comprehensive list): Stratum Code Meaning 0 DCN DCN routing protocol 0 TSP TSP time protocol 1 ATOM Atomic clock (calibrated) 1 WWVB WWVB LF (band 5) radio 1 GOES GOES UHF (band 9) satellite 1 WWV WWV HF (band 7) radio In the case of stratum 2 and greater (secondary reference) this is the four-octet Internet address
of the peer selected for synchronization. Reference Timestamp (sys.reftime, peer.reftime, pkt.reftime): This is the local time, in timestamp format, when the local clock was last updated. If the local clock has never been synchronized,
the value is zero. RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 11 Originate Timestamp (peer.org, pkt.org): This is the local time, in timestamp format, at the peer when its latest NTP message was sent. If the peer becomes unreachable the value is set to zero. Receive Timestamp (peer.rec, pkt.rec): This is the local time, in timestamp format, when the latest NTP message from the peer arrived. If the peer becomes unreachable the value is set to zero. Transmit Timestamp (peer.xmt, pkt.xmt): This is the local time, in timestamp format, at which the NTP message departed the sender. 3.2.2. System Variables Table 1 shows the complete set of system variables. In addition to the common variables described
previously, the following variables are used by the operating system in order to synchronize the
local clock. Local Clock (sys.clock): This is the current local time, in timestamp format. Local time is derived from the hardware clock of the particular machine and increments at intervals depending on the
design used. An appropriate design, including slewing and skew-Compensation mechanisms,
is described in Section 5. Clock Source (sys.peer): This is a selector identifying the current synchronization source. Usually this will be a pointer to a structure containing the peer variables. The special value NULL
indicates there is no currently valid synchronization source. 3.2.3. Peer Variables Table 2 shows the complete set of peer variables. In addition to the common variables described
previously, the following variables are used by the peer management and measurement functions. Configured Bit (peer.config): This is a bit indicating that the association was created from configuration information and should not be demobilized if the peer becomes unreachable. System Variables Name Procedure Leap Indicator sys.leap clock update Stratum sys.stratum clock update Precision sys.precision system Root Delay sys.rootdelay clock update Root Dispersion sys.rootdispersion clock update Reference Clock Ident sys.refid clock update Reference Timestamp sys.reftime clock update Local Clock sys.clock clock update Clock Source sys.peer selection Poll Interval sys.poll local clock Cryptographic Keys sys.keys authentication Table 1. System Variables RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 12 Update Timestamp (peer.update): This is the local time, in timestamp format, when the most recent NTP message was received. It is used in calculating the skew dispersion. Reachability Register (peer.reach): This is a shift register of NTP.WINDOW bits used to determine the reachability status of the peer, with bits entering from the least significant (rightmost) end.
A peer is considered reachable if at least one bit in this register is set to one. Peer Variables Name Procedure Configured Bit peer.config initialization Peer Address peer.peeraddress receive Peer Port peer.peerport receive Host Address peer.hostaddress receive Host Port peer.hostport receive Leap Indicator peer.leap packet Mode peer.mode packet Stratum peer.stratum packet Peer Poll Interval peer.peerpoll packet Host Poll Interval peer.hostpoll poll update Precision peer.precision packet Root Delay peer.rootdelay packet Root Dispersion peer.rootdispersion packet Reference Clock Ident peer.refid packet Reference Timestamp peer.reftime packet Originate Timestamp peer.org packet, clear Receive Timestamp peer.rec packet, clear Transmit Timestamp peer.xmt transmit, clear Update Timestamp peer.update filter, clear Reachability Register peer.reach packet, transmit, clear Peer Timer peer.timer receive, transmit,
poll update Filter Register peer.filter filter Valid Data Counter peer.valid transmit Delay peer.delay filter Offset peer.offset filter Dispersion peer.dispersion filter Authentic Enable Bit peer.authenable authentication Authenticated Bit peer.authentic authentication Host Key Identifier peer.hostkeyid authentication Peer Key Identifier peer.peerkeyid authentication Table 2. Peer Variables RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 13 Peer Timer (peer.timer): This is an integer counter used to control the interval between transmitted NTP messages. Once set to a nonzero value, the counter decrements at one-second intervals
until reaching zero, at which time the transmit procedure is called. Note that the operation of
this timer is independent of local-clock updates, which implies that the timekeeping system and
interval-timer system architecture must be independent of each other. 3.2.4. Packet Variables Table 3 shows the complete set of packet variables. In addition to the common variables described
previously, the following variables are defined. Version Number (pkt.version): This is an integer indicating the version number of the sender. NTP messages will always be sent with the current version number NTP.VERSION and will always
be accepted if the version number matches NTP.VERSION. Exceptions may be advised on a
case-by-case basis at times when the version number is changed. Specific guidelines for
interoperation between this version and previous versions of NTP are summarized in Appendix
D. 3.2.5. Clock-Filter Variables When the filter and selection algorithms suggested in Section 4 are used, the following state variables
are defined in addition to the variables described previously. Packet Variables Name Procedure Peer Address pkt.peeraddress transmit Peer Port pkt.peerport transmit Host Address pkt.hostaddress transmit Host Port pkt.hostport transmit Leap Indicator pkt.leap transmit Version Number pkt.version transmit Mode pkt.mode transmit Stratum pkt.stratum transmit Poll Interval pkt.poll transmit Precision pkt.precision transmit Root Delay pkt.rootdelay transmit Root Dispersion pkt.rootdispersion transmit Reference Clock Ident pkt.refid transmit Reference Timestamp pkt.reftime transmit Originate Timestamp pkt.org transmit Receive Timestamp pkt.rec transmit Transmit Timestamp pkt.xmt transmit Key Identifier pkt.keyid authentication Crypto-Checksum pkt.check authentication Table 3. Packet Variables RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 14 Filter Register (peer.filter): This is a shift register of NTP.SHIFT stages, where each stage stores a 3-tuple consisting of the measured delay, measured offset and calculated dispersion associated
with a single observation. These 3-tuples enter from the most significant (leftmost) right and
are shifted towards the least significant (rightmost) end and eventually discarded as new
observations arrive. Valid Data Counter (peer.valid): This is an integer counter indicating the valid samples remaining in the filter register. It is used to determine the reachability state and when the poll interval
should be increased or decreased. Offset (peer.offset): This is a signed, fixed-point number indicating the offset of the peer clock relative to the local clock, in seconds. Delay (peer.delay): This is a signed fixed-point number indicating the roundtrip delay of the peer clock relative to the local clock over the network path between them, in seconds. Note that this
variable can take on both positive and negative values, depending on clock precision and
skew-error accumulation. Dispersion (peer.dispersion): This is a signed fixed-point number indicating the maximum error of the peer clock relative to the local clock over the network path between them, in seconds. Only
positive values greater than zero are possible. 3.2.6. Authentication Variables When the authentication mechanism suggested in Appendix C is used, the following state variables
are defined in addition to the variables described previously. These variables are used only if the
optional authentication mechanism described in Appendix C is implemented. Authentication Enabled Bit (peer.authenable): This is a bit indicating that the association is to operate in the authenticated mode. Authenticated Bit (peer.authentic): This is a bit indicating that the last message received from the peer has been correctly authenticated. Key Identifier (peer.hostkeyid, peer.peerkeyid, pkt.keyid): This is an integer identifying the cryptographic key used to generate the message-authentication code. Cryptographic Keys (sys.key): This is a set of 64-bit DES keys. Each key is constructed as in the Berkeley Unix distributions, which consists of eight octets, where the seven low-order bits of
each octet correspond to the DES bits 1-7 and the high-order bit corresponds to the DES
odd-parity bit 8. Crypto-Checksum (pkt.check): This is a crypto-checksum computed by the encryption procedure. 3.2.7. Parameters Table 4 shows the parameters assumed for all implementations operating in the Internet system. It
is necessary to agree on the values for these parameters in order to avoid unnecessary network RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 15 overheads and stable peer associations. The following parameters are assumed fixed and applicable
to all associations. Version Number (NTP.VERSION): This is the current NTP version number (3). NTP Port (NTP.PORT): This is the port number (123) assigned by the Internet Assigned Numbers Authority to NTP. Maximum Stratum (NTP.MAXSTRATUM): This is the maximum stratum value that can be encoded as a packet variable, also interpreted as “infinity” or unreachable by the subnet routing
algorithm. Maximum Clock Age (NTP.MAXAGE): This is the maximum interval a reference clock will be considered valid after its last update, in seconds. Maximum Skew (NTP.MAXSKEW): This is the maximum offset error due to skew of the local clock over the interval determined by NTP.MAXAGE, in seconds. The ratio ϕ = NTP.MAXSKEW NTP.MAXAGE is interpreted as the maximum possible skew rate due to all causes. Maximum Distance (NTP.MAXDISTANCE): When the selection algorithm suggested in Section 4 is used, this is the maximum synchronization distance for peers acceptable for synchronization. Minimum Poll Interval (NTP.MINPOLL): This is the minimum poll interval allowed by any peer of the Internet system, in seconds to a power of two. Parameters Name Value Version Number NTP.VERSION 3 NTP Port NTP.PORT 123 Max Stratum NTP.MAXSTRATUM 15 Max Clock Age NTP.MAXAGE 86,400 sec Max Skew NTP.MAXSKEW 1 sec Max Distance NTP.MAXDISTANCE 1 sec Min Polling Interval NTP.MINPOLL 6 (64 sec) Max Polling Interval NTP.MAXPOLL 10 (1024 sec) Min Select Clocks NTP.MINCLOCK 1 Max Select Clocks NTP.MAXCLOCK 10 Min Dispersion NTP.MINDISPERSE .01 sec Max Dispersion NTP.MAXDISPERSE 16 sec Reachability Reg Size NTP.WINDOW 8 Filter Size NTP.SHIFT 8 Filter Weight NTP.FILTER 1 / 2 Select Weight NTP.SELECT 3 / 4 Table 4. Parameters RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 16 Maximum Poll Interval (NTP.MAXPOLL): This is the maximum poll interval allowed by any peer of the Internet system, in seconds to a power of two. Minimum Select Clocks (NTP.MINCLOCK): When the selection algorithm suggested in Section 4 is used, this is the minimum number of peers acceptable for synchronization. Maximum Select Clocks (NTP.MAXCLOCK): When the selection algorithm suggested in Section 4 is used, this is the maximum number of peers considered for selection. Minimum Dispersion (NTP.MINDISPERSE): When the filter algorithm suggested in Section 4 is used, this is the minimum dispersion increment for each stratum level, in seconds. Maximum Dispersion (NTP.MAXDISPERSE): When the filter algorithm suggested in Section 4 is used, this is the maximum peer dispersion and the dispersion assumed for missing data, in
seconds. Reachability Register Size (NTP.WINDOW): This is the size of the reachability register (peer.reach), in bits. Filter Size (NTP.SHIFT): When the filter algorithm suggested in Section 4 is used, this is the size of the clock filter (peer.filter) shift register, in stages. Filter Weight (NTP.FILTER): When the filter algorithm suggested in Section 4 is used, this is the weight used to compute the filter dispersion. Select Weight (NTP.SELECT): When the selection algorithm suggested in Section 4 is used, this is the weight used to compute the select dispersion. 3.3. Modes of Operation Except in broadcast mode, an NTP association is formed when two peers exchange messages and
one or both of them create and maintain an instantiation of the protocol machine, called an
association. The association can operate in one of five modes as indicated by the host-mode variable
(peer.mode): symmetric active, symmetric passive, client, server and broadcast, which are defined
as follows: Symmetric Active (1): A host operating in this mode sends periodic messages regardless of the reachability state or stratum of its peer. By operating in this mode the host announces its
willingness to synchronize and be synchronized by the peer. Symmetric Passive (2): This type of association is ordinarily created upon arrival of a message from a peer operating in the symmetric active mode and persists only as long as the peer is reachable
and operating at a stratum level less than or equal to the host; otherwise, the association is
dissolved. However, the association will always persist until at least one message has been sent
in reply. By operating in this mode the host announces its willingness to synchronize and be
synchronized by the peer. RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 17 Client (3): A host operating in this mode sends periodic messages regardless of the reachability state or stratum of its peer. By operating in this mode the host, usually a LAN workstation, announces
its willingness to be synchronized by, but not to synchronize the peer. Server (4): This type of association is ordinarily created upon arrival of a client request message and exists only in order to reply to that request, after which the association is dissolved. By
operating in this mode the host, usually a LAN time server, announces its willingness to
synchronize, but not to be synchronized by the peer. Broadcast (5): A host operating in this mode sends periodic messages regardless of the reachability state or stratum of the peers. By operating in this mode the host, usually a LAN time server
operating on a high-speed broadcast medium, announces its willingness to synchronize all of
the peers, but not to be synchronized by any of them. A host operating in client mode occasionally sends an NTP message to a host operating in server
mode, perhaps right after rebooting and at periodic intervals thereafter. The server responds by
simply interchanging addresses and ports, filling in the required information and returning the
message to the client. Servers need retain no state information between client requests, while clients
are free to manage the intervals between sending NTP messages to suit local conditions. In these
modes the protocol machine described in this document can be considerably simplified to a simple
remote-procedure-call mechanism without significant loss of accuracy or robustness, especially
when operating over high-speed LANs. In the symmetric modes the client/server distinction (almost) disappears. Symmetric passive mode
is intended for use by time servers operating near the root nodes (lowest stratum) of the synchroni-
zation subnet and with a relatively large number of peers on an intermittent basis. In this mode the
identity of the peer need not be known in advance, since the association with its state variables is
created only when an NTP message arrives. Furthermore, the state storage can be reused when the
peer becomes unreachable or is operating at a higher stratum level and thus ineligible as a
synchronization source. Symmetric active mode is intended for use by time servers operating near the end nodes (highest
stratum) of the synchronization subnet. Reliable time service can usually be maintained with two
peers at the next lower stratum level and one peer at the same stratum level, so the rate of ongoing
polls is usually not significant, even when connectivity is lost and error messages are being returned
for every poll. Normally, one peer operates in an active mode (symmetric active, client or broadcast modes) as
configured by a startup file, while the other operates in a passive mode (symmetric passive or server
modes), often without prior configuration. However, both peers can be configured to operate in the
symmetric active mode. An error condition results when both peers operate in the same mode, but
not symmetric active mode. In such cases each peer will ignore messages from the other, so that
prior associations, if any, will be demobilized due to reachability failure. Broadcast mode is intended for operation on high-speed LANs with numerous workstations and
where the highest accuracies are not required. In the typical scenario one or more time servers on RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 18 the LAN send periodic broadcasts to the workstations, which then determine the time on the basis
of a preconfigured latency in the order of a few milliseconds. As in the client/server modes the
protocol machine can be considerably simplified in this mode; however, a modified form of the
clock selection algorithm may prove useful in cases where multiple time servers are used for
enhanced reliability. 3.4. Event Processing The significant events of interest in NTP occur upon expiration of a peer timer (peer.timer), one of
which is dedicated to each peer with an active association, and upon arrival of an NTP message
from the various peers. An event can also occur as the result of an operator command or detected
system fault, such as a primary reference source failure. This section describes the procedures
invoked when these events occur. 3.4.1. Notation Conventions The NTP filtering and selection algorithms act upon a set of variables for clock offset ( θ , Θ ), roundtrip delay ( δ , ∆ ) and dispersion ( ε , Ε ). When necessary to distinguish between them, lower- case Greek letters are used for variables relative to a peer, while upper-case Greek letters are used
for variables relative to the primary reference source(s), i.e., via the peer to the root of the
synchronization subnet. Subscripts will be used to identify the particular peer when this is not clear
from context. The algorithms are based on a quantity called the synchronization distance ( λ , Λ ), which is computed from the roundtrip delay and dispersion as described below. As described in Appendix H, the peer dispersion ε includes contributions due to measurement error ρ = 1 << sys.precision, skew-error accumulation ϕτ , where ϕ = NTP.MAXSKEW NTP.MAXAGE is the maximum skew rate and τ = sys.clock − peer.update is the interval since the last update, and filter (sample) dispersion ε σ computed by the clock-filter algorithm. The root dispersion Ε includes contributions due to the selected peer dispersion ε and skew-error accumulation ϕτ , together with the root dispersion for the peer itself. The system dispersion includes the select (sample) dispersion ε ξ computed by the clock-select algorithm and the absolute initial clock offset | Θ | provided to the local-clock algorithm. Both ε and Ε are dynamic quantities, since they depend on the elapsed time τ since the last update, as well as the sample dispersions calculated by the algorithms. Each time the relevant peer variables are updated, all dispersions associated with that peer are
updated to reflect the skew-error accumulation. The computations can be summarized as follows: θ ≡ peer.offset , δ ≡ peer.delay , ε ≡ peer.dispersion = ρ + ϕτ + ε σ , λ ≡ ε + | δ | 2 , RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 19 where τ is the interval since the original timestamp (from which θ and δ were determined) was transmitted to the present time and ε σ is the filter dispersion (see clock-filter procedure below). The variables relative to the root of the synchronization subnet via peer i are determined as follows: Θ i ≡ θ i , ∆ i ≡ peer.rootdelay + δ i , Ε i ≡ peer.rootdispersion + ε i + ϕ τ i , Λ i ≡ Ε i + | ∆ i | 2 , where all variables are understood to pertain to the i</i>th peer. Finally, assuming the i</i>th peer is selected
for synchronization, the system variables are determined as follows: Θ = combined final offset , ∆ = ∆ i , Ε = Ε i + ε ξ + | Θ | , Λ = Λ i , where ε ξ is the select dispersion (see clock-selection procedure below). Informal pseudo-code which accomplishes these computations is presented below. Note that the
pseudo-code is represented in no particular language, although it has many similarities to the C
language. Specific details on the important algorithms are further illustrated in the C-language
routines in Appendix I. 3.4.2. Transmit Procedure The transmit procedure is executed when the peer timer decrements to zero for all modes except
client mode with a broadcast server and server mode in all cases. In client mode with a broadcast
server messages are never sent. In server mode messages are sent only in response to received
messages. This procedure is also called by the receive procedure when an NTP message arrives that
does not result in a persistent association. begin transmit procedure The following initializes the packet buffer and copies the packet variables. The value skew is
necessary to account for the skew-error accumulated over the interval since the local clock was last
set. pkt.peeraddr ← peer.hostaddr; /* copy system and peer variables */ pkt.peerport ← peer.hostport; pkt.hostaddr ← peer.peeraddr; pkt.hostport ← peer.peerport; pkt.leap ← sys.leap; pkt.version ← NTP.VERSION; RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 20 pkt.mode ← peer.mode; pkt.stratum ← sys.stratum; pkt.poll ← peer.hostpoll; pkt.precision ← sys.precision; pkt.rootdelay ← sys.rootdelay; if (sys.leap = 11 2 or (sys.clock – sys.reftime) > NTP.MAXAGE) skew ← NTP.MAXSKEW; else skew ← ϕ( sys.clock − sys.reftime ) ; pkt.rootdispersion ← sys.rootdispersion + ( 1 << sys.precision ) + skew; pkt.refid ← sys.refid; pkt.reftime ← sys.reftime; The transmit timestamp pkt.xmt will be used later in order to validate the reply; thus, implementa-
tions must save the exact value transmitted. In addition, the order of copying the timestamps should
be designed so that the time to format and copy the data does not degrade accuracy. pkt.org ← peer.org; /* copy timestamps */ pkt.rec ← peer.rec; pkt.xmt ← sys.clock; peer.xmt ← pkt.xmt; The call to encrypt is implemented only if authentication is implemented. If authentication is
enabled, the delay to encrypt the authenticator may degrade accuracy. Therefore, implementations
should include a system state variable (not mentioned elsewhere in this specification) which contains
an offset calculated to match the expected encryption delay and correct the transmit timestamp as
obtained from the local clock. #ifdef (authentication implemented) /* see Appendix C */ call encrypt;
#endef send packet; The reachability register is shifted one position to the left, with zero replacing the vacated bit. If all
bits of this register are zero, the clear procedure is called to purge the clock filter and reselect the
synchronization source, if necessary. If the association was not configured by the initialization
procedure, the association is demobilized. peer.reach ← peer.reach << 1; /* update reachability */ if (peer.reach = 0 and peer.config = 0) begin demobilize association;
exit;
endif RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 21 If valid data have been shifted into the filter register at least once during the preceding two poll
intervals (low-order bit of peer.reach set to one), the valid data counter is incremented. After eight
such valid intervals the poll interval is incremented. Otherwise, the valid data counter and poll
interval are both decremented and the clock-filter procedure called with zero values for offset and
delay and NTP.MAXDISPERSE for dispersion. The clock-select procedure is called to reselect the
synchronization source, if necessary. if (peer.reach & 6 ≠ 0) /* test two low-order bits (shifted) */ if (peer.valid < NTP.SHIFT) /* valid data received */ peer.valid ← peer.valid + 1; else peer.hostpoll ← peer.hostpoll + 1; else begin peer.valid ← peer.valid − 1; /* nothing heard */ peer.hostpoll ← peer.hostpoll − 1); call clock-filter(0, 0, NTP.MAXDISPERSE);
call clock-select; /* select clock source */ endif call poll-update;
end transmit procedure; 3.4.3. Receive Procedure The receive procedure is executed upon arrival of an NTP message. It validates the message,
interprets the various modes and calls other procedures to filter the data and select the synchroni-
zation source. If the version number in the packet does not match the current version, the message
may be discarded; however, exceptions may be advised on a case-by-case basis at times when the peer.mode → mode ↓ sym act
1 sym pas
2 client
3 server
4 bcst
5 sym active recv pkt recv 2 xmit 2 xmit 1,2 sym passive recv error recv 2 error error client xmit 2 xmit 2 error xmit xmit 1 server recv 2 error recv error error broadcast recv 1,2 error recv 1 error error Notes: 1. A broadcast server responds directly to the client with pkt.org and pkt.rec containing correct values. At other times the server simply broadcasts the local time with pkt.org and pkt.rec set
to zero. 2. Ordinarily, these mode combinations would not be used; however, within the limits of the specification, they would result in correct time. Table 5. Modes and Actions RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 22 version is changed. If the NTP control messages described in Appendix B are implemented and the
packet mode is 6 (control), the control-message procedure is called. The source and destination
Internet addresses and ports in the IP and UDP headers are matched to the correct peer. If there is
no match a new instantiation of the protocol machine is created and the association mobilized. begin receive procedure if (pkt.version ≠ NTP.VERSION) exit; #ifdef (control messages implemented) if (pkt.mode = 6) call control-message; #endef for (all associations) /* access control goes here */ match addresses and ports to associations; if (no matching association) call receive-instantiation procedure; /* create association */ The call to decrypt is implemented only if authentication is implemented. #ifdef (authentication implemented) /* see Appendix C */ call decrypt;
#endef If the packet mode is nonzero, this becomes the value of mode used in the following step; otherwise,
the peer is an old NTP version and mode is determined from the port numbers as described in Section
3.3. if (pkt.mode = 0) /* for compatibility with old versions */ mode ← (see Section 3.3); else mode ← pkt.mode; Table 5 shows for each combination of peer.mode and mode the resulting case labels. case ( mode, peer.hostmode) /* see Table 5 */ If error the packet is simply ignored and the association demobilized, if not previously configured. error: if (peer.config = 0) demobilize association; /* see no evil */ break; If recv the packet is processed and the association marked reachable if tests five through eight (valid
header) enumerated in the packet procedure succeed. If, in addition, tests one through four succeed
(valid data), the clock-update procedure is called to update the local clock. Otherwise, if the
association was not previously configured, it is demobilized. recv: call packet; /* process packet */ if (valid header) begin /* if valid header, update local clock */ peer.reach ← peer.reach | 1; RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 23 if (valid data) call clock-update;
endif else if (peer.config = 0) demobilize association; break; If xmit the packet is processed and an immediate reply is sent. The association is then demobilized
if not previously configured. xmit: call packet; /* process packet */ peer.hostpoll ← peer.peerpoll; /* send immediate reply */ call poll-update;
call transmit;
if (peer.config = 0) demobilize association; break; If pkt the packet is processed and the association marked reachable if tests five through eight (valid
header) enumerated in the packet procedure succeed. If, in addition, tests one through four succeed
(valid data), the clock-update procedure is called to update the local clock. Otherwise, if the
association was not previously configured, an immediate reply is sent and the association demobi-
lized. pkt: call packet; /* process packet */ if (valid header) begin /* if valid header, update local clock */ peer.reach ← peer.reach | 1; if (valid data) call clock-update;
endif else if (peer.config = 0) begin peer.hostpoll ← peer.peerpoll; /* send immediate reply */ call poll-update;
call transmit;
demobilize association;
endif endcase end receive procedure; 3.4.4. Packet Procedure The packet procedure checks the message validity, computes delay/offset samples and calls other
procedures to filter the data and select the synchronization source. Test 1 requires the transmit
timestamp not match the last one received from the same peer; otherwise, the message might be an
old duplicate. Test 2 requires the originate timestamp match the last one sent to the same peer;
otherwise, the message might be out of order, bogus or worse. In case of broadcast mode (5) the
apparent roundtrip delay will be zero and the full accuracy of the time-transfer operation may not RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 24 be achievable. However, the accuracy achieved may be adequate for most purposes. The poll-update
procedure is called with argument peer.hostpoll (peer.peerpoll may have changed). begin packet procedure peer.rec ← sys.clock; /* capture receive timestamp */ if (pkt.mode ≠ 5) begin test1 ← ( pkt.xmt ≠ peer.org ) ; /* test 1 */ test2 ← ( pkt.org = peer.xmt ) ; /* test 2 */ endif else begin pkt.org ← peer.rec; /* fudge missing timestamps */ pkt.rec ← pkt.xmt; test1 ← true; /* fake tests */ test2 ← true; endif peer.org ← pkt.xmt; /* update originate timestamp */ peer.peerpoll ← pkt.poll; /* adjust poll interval */ call poll-update(peer.hostpoll); Test 3 requires that both the originate and receive timestamps are nonzero. If either of the timestamps
are zero, the association has not synchronized or has lost reachability in one or both directions. test 3 ← ( pkt.org ≠ 0 and pkt.rec ≠ 0 ) ; /* test 3 */ The roundtrip delay and clock offset relative to the peer are calculated as follows. Number the times
of sending and receiving NTP messages as shown in Figure 2 and let i be an even integer. Then
T i</i>-3 , T i</i>-2 , T i</i>-1 and T i are the contents of the pkt.org, pkt.rec, pkt.xmt and peer.rec variables, respectively. The clock offset θ , roundtrip delay δ and dispersion ε of the host relative to the peer is: δ = ( T i − T i − 3 ) − ( T i − 1 − T i − 2 ) , θ = ( T i − 2 − T i − 3 ) + ( T i − 1 − T i ) 2 , ε = ( 1 < < sys.precision ) + ϕ( T i − T i − 3 ) , T i − 2 T i − 1 T i − 3 T i Peer Host Figure 2. Calculating Delay and Offset RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 25 where, as before, ϕ = NTP.MAXSKEW NTP.MAXAGE . The quantity ε represents the maximum error or dispersion due to measurement error at the host and local-clock skew accumulation over the interval since the
last message was transmitted to the peer. Subsequently, the dispersion will be updated by the
clock-filter procedure. The above method amounts to a continuously sampled, returnable-time system, which is used in
some digital telephone networks [BEL86]. Among the advantages are that the order and timing of
the messages are unimportant and that reliable delivery is not required. Obviously, the accuracies
achievable depend upon the statistical properties of the outbound and inbound data paths. Further
analysis and experimental results bearing on this issue can be found in [MIL90] and in Appendix
H. Test 4 requires that the calculated delay be within “reasonable” bounds: test4 ← ( | δ | < NTP.MAXDISPERSE and ε < NTP.MAXDISPERSE ) ; /* test 4 */ Test 5 is implemented only if the authentication mechanism described in Appendix C is imple-
mented. It requires either that authentication be explicitly disabled or that the authenticator be
present and correct as determined by the decrypt procedure. #ifdef (authentication implemented) /* test 5 */ test5 ← (( peer.config = 1 and peer.authenable = 0 ) or peer.authentic = 1 ) ; #endef Test 6 requires the peer clock be synchronized and the interval since the peer clock was last updated
be positive and less than NTP.MAXAGE. Test 7 insures that the host will not synchronize on a peer
with greater stratum. Test 8 requires that the header contains “reasonable” values for the pkt.root-
delay and pkt.rootdispersion fields. test6 ← ( pkt.leap ≠ 11 2 and /* test 6 */ pkt.reftime ≤ pkt.xmt < pkt.reftime + NTP.MAXAGE) test 7 ← pkt.stratum ≤ sys.stratum and /* test 7 */ pkt.stratum < NTP.MAXSTRATUM; test 8 ← ( | pkt.rootdelay| < NTP.MAXDISPERSE and /* test 8 */ pkt.rootdispersion < NTP.MAXDISPERSE ) ; With respect to further processing, the packet includes valid (synchronized) data if tests one through
four succeed ( test</i>1 & test</i>2 & test</i>3 & test</i>4 = 1 ) , regardless of the remaining tests. Only packets with valid data can be used to calculate offset, delay and dispersion values. The packet includes a
valid header if tests five through eight succeed ( test</i>5 & test</i>6 & test</i>7 & test</i>8 = 1 ) , regardless of the remaining tests. Only packets with valid headers can be used to determine whether a peer can be
selected for synchronization. Note that test</i>1 and test</i>2 are not used in broadcast mode (forced to
true ), since the originate and receive timestamps are undefined. RFC-1305 Network Time Protocol (Version 3) March 1992 Mills Page 26 The clock-filter procedure is called to produce the delay (peer.delay), offset (peer.offset) and
dispersion (peer.dispersion) for the peer. Specification of the clock-filter algorithm is not an integral
part of the NTP specification, since there may be other algorithms that work well in practice.
However, one found to work well in the Internet environment is described in Section 4 and its use
is recommended. if (not valid header) exit;
peer.leap ← pkt.leap; /* copy packet variables */ peer.stratum ← pkt.stratum; peer.precision ← pkt.precision; peer.rootdelay ← pkt.rootdelay; peer.rootdispersion ← pkt.rootdispersion; peer.refid ← pkt.refid; peer.reftime ← pkt.reftime; if (valid data) call clock-filter( θ , δ , ε

Comments