01, last minute has 61 seconds

10, last minute has 59 seconds)

11, alarm condition (clock not synchronized)

@Z_TBL_END =

Clock Source: This is a six-bit integer indicating the current
synchronization source, with values coded as follows:

@Z_TBL_BEG = COLUMNS(2), DIMENSION(IN), COLWIDTHS(E1,E8), WIDTH(5.0000),
ABOVE(.0830), BELOW(.0830), HGUTTER(.0560), KEEP(OFF), ALIGN(CT)

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT

0, unspecified or unknown

1, Calibrated atomic clock (e.g.,, HP 5061)

2, VLF (band 4) or LF (band 5) radio (e.g.,, OMEGA,, WWVB)

3, HF (band 7) radio (e.g.,, CHU,, MSF,, WWV/H)

4, UHF (band 9) satellite (e.g.,, GOES,, GPS)

5, local net (e.g.,, DCN,, TSP,, DTS)
6, UDP/NTP

7, UDP/TIME

8, eyeball-and-wristwatch

9, telephone modem (e.g.,, NIST)

10-63, reserved

@Z_TBL_END =

System Event Counter: This is a four-bit integer indicating the number
of system exception events occurring since the last time the system
status word was returned in a response or included in a trap message.
The counter is cleared when returned in the status field of a response
and freezes when it reaches the value 15.

System Event Code: This is a four-bit integer identifying the latest
system exception event, with new values overwriting previous values, and
coded as follows:

@Z_TBL_BEG = COLUMNS(2), DIMENSION(IN), COLWIDTHS(E1,E8), WIDTH(5.0000),

ABOVE(.0830), BELOW(.0830), HGUTTER(.0560), KEEP(OFF), ALIGN(CT)

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT

0, unspecified

1, system restart

2, system or hardware fault

3, system new status word (leap bits or synchronization change)

4, system new synchronization source or stratum (sys.peer or sys.stratum
change)

5, system clock reset (offset correction exceeds CLOCK.MAX)

6, system invalid time or date (see NTP specification)

7, system clock exception (see system clock status word)

8-15, reserved

@Z_TBL_END =

Peer Status Word

A peer status word is returned in the status field of a response to a
read status, read variables or write variables command and appears also
in the list of association identifiers and status words returned by a
read status command with a zero association identifier. The format of a
peer status word is as follows:

Peer Status: This is a five-bit code indicating the status of the peer
determined by the packet procedure, with bits assigned as follows:

@Z_TBL_BEG = COLUMNS(2), DIMENSION(IN), COLWIDTHS(E1,E8), WIDTH(5.0000),
ABOVE(.0830), BELOW(.0830), HGUTTER(.0560), KEEP(OFF), ALIGN(CT)

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT

0, configured (peer.config)
1, authentication enabled (peer.authenable)

2, authentication okay (peer.authentic)

3, reachability okay (peer.reach <F128M>?<F255D> 0)

4, reserved

@Z_TBL_END =

Peer Selection (Sel): This is a three-bit integer indicating the status
of the peer determined by the clock-selection procedure, with values
coded as follows:

@Z_TBL_BEG = COLUMNS(2), DIMENSION(IN), COLWIDTHS(E1,E8), WIDTH(5.0000),
ABOVE(.0830), BELOW(.0830), HGUTTER(.0560), KEEP(OFF), ALIGN(CT)

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT

0, rejected

1, passed sanity checks (tests 1 through 8 in Section 3.4.3)

2, passed correctness checks (intersection algorithm in Section 4.2.1)

3, passed candidate checks (if limit check implemented)

4, passed outlyer checks (clustering algorithm in Section 4.2.2)

5, current synchronization source; max distance exceeded (if limit check
implemented)

6, current synchronization source; max distance okay

7, reserved

@Z_TBL_END =

Peer Event Counter: This is a four-bit integer indicating the number of
peer exception events that occurred since the last time the peer status
word was returned in a response or included in a trap message. The
counter is cleared when returned in the status field of a response and
freezes when it reaches the value 15.

Peer Event Code: This is a four-bit integer identifying the latest peer
exception event, with new values overwriting previous values, and coded
as follows:

@Z_TBL_BEG = COLUMNS(2), DIMENSION(IN), COLWIDTHS(E1,E8), WIDTH(5.0000),
ABOVE(.0830), BELOW(.0830), HGUTTER(.0560), KEEP(OFF), ALIGN(CT)

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT

0, unspecified

1, peer IP error

2, peer authentication failure (peer.authentic bit was one now zero)

3, peer unreachable (peer.reach was nonzero now zero)

4, peer reachable (peer.reach was zero now nonzero)

5, peer clock exception (see peer clock status word)

6-15, reserved
@Z_TBL_END =

Clock Status Word

There are two ways a reference clock can be attached to a NTP service
host, as an dedicated device managed by the operating system and as a
synthetic peer managed by NTP. As in the read status command, the
association identifier is used to identify which one, zero for the
system clock and nonzero for a peer clock. Only one system clock is
supported by the protocol, although many peer clocks can be supported. A
system or peer clock status word appears in the status field of the
response to a read clock variables or write clock variables command.
This word can be considered an extension of the system status word or
the peer status word as appropriate. The format of the clock status word
is as follows:

Clock Status: This is an eight-bit integer indicating the current clock
status, with values coded as follows:

@Z_TBL_BEG = COLUMNS(2), DIMENSION(IN), COLWIDTHS(E1,E8), WIDTH(5.0000),
ABOVE(.0830), BELOW(.0830), HGUTTER(.0560), KEEP(OFF), ALIGN(CT)

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT

0, clock operating within nominals

1, reply timeout

2, bad reply format

3, hardware or software fault

4, propagation failure

5, bad date format or value

6, bad time format or value

7-255, reserved

@Z_TBL_END =

Clock Event Code: This is an eight-bit integer identifying the latest
clock exception event, with new values overwriting previous values. When
a change to any nonzero value occurs in the radio status field, the
radio status field is copied to the clock event code field and a system
or peer clock exception event is declared as appropriate.

Error Status Word

An error status word is returned in the status field of an error
response as the result of invalid message format or contents. Its
presence is indicated when the E (error) bit is set along with the
response (R) bit in the response. It consists of an eight-bit integer
coded as follows:

@Z_TBL_BEG = COLUMNS(2), DIMENSION(IN), COLWIDTHS(E1,E8), WIDTH(5.0000),
ABOVE(.0830), BELOW(.0830), HGUTTER(.0560), KEEP(OFF), ALIGN(CT)

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT

0, unspecified

1, authentication failure

2, invalid message length or format
3, invalid opcode

4, unknown association identifier

5, unknown variable name

6, invalid variable value

7, administratively prohibited

8-255, reserved

@Z_TBL_END =

Commands

Commands consist of the header and optional data field shown in Figure
6. When present, the data field contains a list of identifiers or
assignments in the form

<<identifier>>[=<<value>>],<<identifier>>[=<<value>>],...

where <<identifier>> is the ASCII name of a system or peer variable
specified in Table 2 or Table 3 and <<value>> is expressed as a decimal,
hexadecimal or string constant in the syntax of the C programming
language. Where no ambiguity exists, the <169>sys.<170> or

<169>peer.<170> prefixes shown in Table 2 or Table 4 can be suppressed.
Whitespace (ASCII nonprinting format effectors) can be added to improve
readability for simple monitoring programs that do not reformat the data
field. Internet addresses are represented as four octets in the form
[n.n.n.n], where n is in decimal notation and the brackets are optional.
Timestamps, including reference, originate, receive and transmit values,
as well as the logical clock, are represented in units of seconds and
fractions, preferably in hexadecimal notation, while delay, offset,
dispersion and distance values are represented in units of milliseconds
and fractions, preferably in decimal notation. All other values are
represented as-is, preferably in decimal notation.

Implementations may define variables other than those listed in Table 2
or Table 3. Called extramural variables, these are distinguished by the
inclusion of some character type other than alphanumeric or <169>.<170>
in the name. For those commands that return a list of assignments in the
response data field, if the command data field is empty, it is expected
that all available variables defined in Table 3 or Table 4 of the NTP
specification will be included in the response. For the read commands,
if the command data field is nonempty, an implementation may choose to
process this field to individually select which variables are to be
returned.

Commands are interpreted as follows:

Read Status (1): The command data field is empty or contains a list of
identifiers separated by commas. The command operates in two ways
depending on the value of the association identifier. If this identifier
is nonzero, the response includes the peer identifier and status word.
Optionally, the response data field may contain other information, such
as described in the Read Variables command. If the association
identifier is zero, the response includes the system identifier (0) and
status word, while the data field contains a list of binary-coded pairs

<<association identifier>> <<status word>>,

one for each currently defined association.
Read Variables (2): The command data field is empty or contains a list
of identifiers separated by commas. If the association identifier is
nonzero, the response includes the requested peer identifier and status
word, while the data field contains a list of peer variables and values
as described above. If the association identifier is zero, the data
field contains a list of system variables and values. If a peer has been
selected as the synchronization source, the response includes the peer
identifier and status word; otherwise, the response includes the system
identifier (0) and status word.

Write Variables (3): The command data field contains a list of
assignments as described above. The variables are updated as indicated.
The response is as described for the Read Variables command.

Read Clock Variables (4): The command data field is empty or contains a
list of identifiers separated by commas. The association identifier
selects the system clock variables or peer clock variables in the same
way as in the Read Variables command. The response includes the
requested clock identifier and status word and the data field contains a
list of clock variables and values, including the last timecode message
received from the clock.

Write Clock Variables (5): The command data field contains a list of
assignments as described above. The clock variables are updated as
indicated. The response is as described for the Read Clock Variables
command.

Set Trap Address/Port (6): The command association identifier, status
and data fields are ignored. The address and port number for subsequent
trap messages are taken from the source address and port of the control
message itself. The initial trap counter for trap response messages is
taken from the sequence field of the command. The response association
identifier, status and data fields are not significant. Implementations
should include sanity timeouts which prevent trap transmissions if the
monitoring program does not renew this information after a lengthy
interval.

Trap Response (7): This message is sent when a system, peer or clock
exception event occurs. The opcode field is 7 and the R bit is set. The
trap counter is incremented by one for each trap sent and the sequence
field set to that value. The trap message is sent using the IP address
and port fields established by the set trap address/port command. If a
system trap the association identifier field is set to zero and the
status field contains the system status word. If a peer trap the
association identifier field is set to that peer and the status field
contains the peer status word. Optional ASCII-coded information can be
included in the data field.

Appendix C. Authentication Issues

NTP robustness requirements are similar to those of other multiple-peer
distributed protocols used for network routing, management and file
access. These include protection from faulty implementations, improper
operation and possibly malicious replay attacks with or without data
modification. These requirements are especially stringent with
distributed protocols, since damage due to failures can propagate
quickly throughout the network, devastating archives, routes and
monitoring systems and even bring down major portions of the network in
the fashion of the classic Internet Worm.

The access-control mechanism suggested in the NTP specification responds
to these requirements by limiting access to trusted peers. The various
sanity checks resist most replay and spoofing attacks by discarding old

duplicates and using the originate timestamp as a one-time pad, since it
is unlikely that even a synchronized peer can predict future timestamps
with the precision required on the basis of past observations alone. In
addition, the protocol environment resists jamming attacks by employing
redundant time servers and diverse network paths. Resistance to
stochastic disruptions, actual or manufactured, are minimized by careful
design of the filtering and selection algorithms.

However, it is possible that a determined intruder can disrupt
timekeeping operations between peers by subtle modifications of NTP
message data, such as falsifying header fields or certain timestamps. In
cases where protection from even these types of attacks is required, a
specifically engineered message-authentication mechanism based on
cryptographic techniques is necessary. Typical mechanisms involve the
use of cryptographic certificates, algorithms and key media, together
with secure media databases and key-management protocols. Ongoing
research efforts in this area are directed toward developing a standard
methodology that can be used with many protocols, including NTP.
However, while it may eventually be the case that ubiquitous, widely
applicable authentication methodology may be adopted by the Internet
community and effectively overtake the mechanism described here, it does
not appear that specific standards and implementations will happen
within the lifetime of this particular version of NTP.

The NTP authentication mechanism described here is intended for interim
use until specific standards and implementations operating at the
network level or transport level are available. Support for this
mechanism is not required in order to conform to the NTP specification
itself. The mechanism, which operates at the application level, is
designed to protect against unauthorized message-stream modification and
misrepresentation of source by insuring that unbroken, authenticated
paths exist between a trusted, stratum-one server in a particular
synchronization subnet and all other servers in that subnet. It employs
a crypto-checksum, computed by the sender and checked by the receiver,
together with a set of predistributed algorithms, certificates and
cryptographic keys indexed by a key identifier included in the message.
However, there are no provisions in NTP itself to distribute or maintain
the certificates, algorithms or keys. These quantities may occasionally
be changed, which may result in inconsistent key information while
rekeying is in progress. The nature of NTP itself is quite tolerant to
such disruptions, so no particular provisions are included to deal with
them.

The intent of the authentication mechanism is to provide a framework
that can be used in conjunction with selected mode combinations to build
specific plans to manage clockworking communities and implement policy
as necessary. It can be selectively enabled or disabled on a per-peer
basis. There is no specific plan proposed to manage the use of such
schemes; although several possibilities are immediately obvious. In one
scenario a group of time servers peers among themselves using symmetric

modes and shares one secret key, say key 1, while another group of
servers peers among themselves using symmetric modes and shares another
secret key, say key 2. Now, assume by policy it is decided that selected
servers in group 1 can provide synchronization to group 2, but not the
other way around. The selected servers in group 1 are given key 2, but
operated only in server mode, so cannot accept synchronization from
group 2; however, group 2 has authenticated access to group-1 servers.
Many other scenarios are possible with suitable combinations of modes
and keys.

A packet format and crypto-checksum procedure appropriate for NTP is
specified in the following sections. The cryptographic information is
carried in an authenticator which follows the (unmodified) NTP header
fields. The crypto-checksum procedure uses the Data Encryption Standard
(DES) [NBS77]; however, only the DES encryption algorithm is used and
the decryption algorithm is not necessary. This feature is specifically
targeted toward governmental sensitivities on the export of
cryptographic technology, since the DES decryption algorithm need not be
included in NTP software distributions and thus cannot be extracted and
used in other applications to avoid message data disclosure.

NTP Authentication Mechanism

When it is created and possibly at other times, each association is
allocated variables identifying the certificate authority, encryption
algorithm, cryptographic key and possibly other data. The specific
procedures to allocate and initialize these variables are beyond the
scope of this specification, as are the association of the identifiers
and keys and the management and distribution of the keys themselves. For
example and consistency with the conventions of the NTP specification, a
set of appropriate peer and packet variables might include the
following:

Authentication Enabled Bit (peer.authenable): This is a bit indicating
that the association is to operate in the authenticated mode. For
configured peers this bit is determined from the startup environment.
For non-configured peers, this bit is set to one if an arriving message
includes the authenticator and set to zero otherwise.

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. The system variable peer.hostkeyid is used for
active associations. The peer.peerkeyid variable is initialized at zero
(unspecified) when the association is mobilized. For purposes of
authentication an unassigned value is interpreted as zero (unspecified).

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. By convention, the unspecified key 0 (zero), consisting of
eight odd-parity zero octets, is used for testing and presumed known
throughout the NTP community. The remaining keys are distributed using
methods outside the scope of NTP.

Crypto-Checksum (pkt.check): This is a crypto-checksum computed by the
encryption procedure.

The authenticator field consists of two subfields, one consisting of the
pkt.keyid variable and the other the pkt.check variable computed by the
encrypt procedure, which is called by the transmit procedure described
in the NTP specification, and by the decrypt procedure, which is called
by the receive procedure described in the NTP specification. Its
presence is revealed by the fact the total datagram length according to
the UDP header is longer than the NTP message length, which includes the
header plus the data field, if present. For authentication purposes, the
NTP message is zero-padded if necessary to a 64-bit boundary, although
the padding bits are not considered part of the NTP message itself. The
authenticator format shown in Figure 7<$&fig7> has 96 bits, including a
32-bit key identifier and 64-bit crypto-checksum, and is aligned on a
32-bit boundary for efficient computation. Additional information
required in some implementations, such as certificate authority and
encryption algorithm, can be inserted between the (padded) NTP message
and the key identifier, as long as the alignment conditions are met.
Like the authenticator itself, this information is not included in the
crypto-checksum. Use of these data are beyond the scope of this
specification. These conventions may be changed in future as the result
of other standardization activities.

NTP Authentication Procedures
When authentication is implemented there are two additional procedures
added to those described in the NTP specification. One of these
(encrypt) constructs the crypto-checksum in transmitted messages, while
the other (decrypt) checks this quantity in received messages. The
procedures use a variant of the cipher-block chaining method described
in [NBS80] as applied to DES. In principal, the procedure is independent
of DES and requires only that the encryption algorithm operate on 64-bit
blocks. While the NTP authentication mechanism specifies the use of DES,
other algorithms could be used by prior arrangement.

Encrypt Procedure

For ordinary NTP messages the encryption procedure operates as follows.
If authentication is not enabled, the procedure simply exits. If the
association is active (modes 1, 3, 5), the key is determined from the
system key identifier. If the association is passive (modes 2, 4) the
key is determined from the peer key identifier, if the authentic bit is

set, or as the default key (zero) otherwise. These conventions allow
further protection against replay attacks and keying errors, as well as
facilitate testing and migration to new versions. The crypto-checksum is
calculated using the 64-bit NTP header and data words, but not the
authenticator or padding bits.

begin encrypt procedure
        if (<$Eroman peer.authenable~=~0>) exit;                /* do
nothing if not enabled */
        if (<$Eroman {peer.hostmode~=~1~bold or~peer.hostmode~=~3~bold
or~peer.hostmode ~=~5}>)
                <$Ekeyid~<<-~roman peer.hostkeyid>;             /*
active modes use system key */
        else
                if (<$Eroman peer.authentic~=~1>)               /*
passive modes use peer key */
                         <$Ekeyid~<<-~roman peer.peerkeyid>;
                else
                         <$Ekeyid~<<-~0>;                       /*
unauthenticated use key 0 */
        <$Etemp~<<-~0>;                                 /* calculate
crypto-checksum */
        for (each 64-bit header and data word) begin
                <$Etemp~<<-~temp~roman bold xor~word>;
                <$Etemp~<<-~roman DES (temp,~keyid)>;
                endfor;
        <$Eroman pkt.keyid~<<-~keyid>;                          /*
insert packet variables */
        <$Eroman pkt.check~<<-~temp>;
        end encrypt procedure;

Decrypt Procedure

For ordinary messages the decryption procedure operates as follows. If
the peer is not configured, the data portion of the message is inspected
to determine if the authenticator fields are present. If so,
authentication is enabled; otherwise, it is disabled. If authentication
is enabled and the authenticator fields are present and the crypto-
checksum succeeds, the authentication bit is set to one; otherwise, it
is set to zero.

begin decrypt procedure
        <$Eroman peer.authentic~<<-~0>;
        if (<$Eroman peer.config~=~0>)                          /* if
not configured, enable per packet */
                if (authenticator present)
                        <$Eroman peer.authenable~<<-~1>;
                else
                        <$Eroman peer.authenable~<<-~0>;
        if (<$Eroman peer.authenable~=~0> or authenticator not present))

exit;
        <$Eroman {peer.peerkeyid~<<-~pkt.keyid}>;               /* use
peer key */
        <$Etemp~<<-~0>;                                 /* calculate
crypto-checksum */
        for (each 64-bit header and data word) begin
                <$Etemp~<<-~temp~roman bold xor~word>;
                <$Etemp~<<-~roman DES (temp,~roman peer.peerkeyid)>;
                endfor;
        if (temp == pkt.check) <$Eroman peer.authentic~<<-~1>;  /*
declare result */
        end decrypt procedure;

Control-Message Procedures

In anticipation that the functions provided by the NTP control messages
will eventually be subsumed by a comprehensive network-managment
function, the peer variables are not used for control message
authentication. If an NTP command message is received with an
authenticator field, the crypto-checksum is computed as in the decrypt
procedure and the response message includes the authenticator field as
computed by the encrypt procedure. If the received authenticator is
correct, the key for the response is the same as in the command;
otherwise, the default key (zero) is used. Commands causing a change to
the peer data base, such as the write variables and set trap
address/port commands, must be correctly authenticated; however, the
remaining commands are normally not authenticated in order to minimize
the encryption overhead.

Appendix D. Differences from Previous Versions.

The original NTP, later called NTP Version 0, was described in RFC-958
[MIL85c]. Subsequently, Version 0 was superseded by Version 1 (RFC-1059
[MIL88a]), and Version 2 (RFC-1119 [MIL89]. The Version-2 description
was split into two documents, RFC-1119 defining the architecture and
specifying the protocol and algorithms, and another [MIL90b] describing
the service model, algorithmic analysis and operating experience. In
previous versions these two objectives were combined in one document.
While the architecture assumed in Version 3 is identical to Version 2,
the protocols and algorithms differ in minor ways. Differences between
NTP Version 3 and previous versions are described in this Appendix. Due
to known bugs in very old implementations, continued support for
Version-0 implementations is not recommended. It is recommended that new
implementations follow the guidelines below when interoperating with
older implementations.

Version 3 neither changes the protocol in any significant way nor
obsoletes previous versions or existing implementations. The main
motivation for the new version is to refine the analysis and
implementation models for new applications at much higher network speeds

to the gigabit-per-second regime and to provide for the enhanced
stability, accuracy and precision required at such speeds. In
particular, the sources of time and frequency errors have been
rigorously examined and error bounds established in order to improve
performance, provide a model for correctness assertions and indicate
timekeeping quality to the user. Version 3 also incorporates two new
optional features, (1) an algorithm to combine the offsets of a number
of peer time servers in order to enhance accuracy and (2) improved
local-clock algorithms which allow the poll intervals on all
synchronization paths to be substantially increased in order to reduce
network overhead. Following is a summary of previous versions of the
protocol together with details of the Version 3 changes.

1.
Version 1 supports no modes other than symmetric-active and symmetric-
passive, which are determined by inspecting the port-number fields of
the UDP packet header. The peer mode can be determined explicitly from
the packet-mode variable (pkt.mode) if it is nonzero and implicitly from
the source port (pkt.peerport) and destination port (pkt.hostport)
variables if it is zero. For the case where pkt.mode is zero the mode is
determined as follows:

@Z_TBL_BEG = COLUMNS(3), DIMENSION(IN), WIDTH(5.0000), ABOVE(.1670),
BELOW(.0830), HGUTTER(.3330), BOX(Z_SINGLE), KEEP(ON), ALIGN(CT),
L1(R1C0..R1C3)

@Z_TBL_BODY = TABLE HEADER, TABLE HEADER, TABLE HEADER

pkt.peerport, pkt.hostport, Mode

@Z_TBL_BODY = TABLE TEXT, TABLE TEXT, TABLE TEXT

NTP.PORT, NTP.PORT, symmetric active

NTP.PORT, not NTP.PORT, server

not NTP.PORT, NTP.PORT, client

@Z_TBL_BODY = TABLE HEADER, TABLE HEADER, TABLE HEADER

not NTP.PORT, not NTP.PORT, not possible

@Z_TBL_END =

Note that it is not possible in this case to distinguish between
symmetric active and symmetric passive modes. Use of the pkt.mode and
NTP.PORT variables in this way is not recommended and may not be
supported in future versions of the protocol. The low-order three bits
of the first octet, specified as zero in Version 1, are used for the
mode field in Version 2. Version-2 and Version-3 implementations

interoperating with Version-1 implementations should operate in a
passive mode only and use the value one in the version number
(pkt.version) field and zero in the mode (pkt.mode) field in transmitted
messages.

2.

Version 1 does not support the NTP control message described in Appendix
B. Certain old versions of the Unix NTP daemon ntpd use the high-order
bits of the stratum field (pkt.stratum) for control and monitoring
purposes. While these bits are never set during normal Version-1,
Version-2 or Version-3 operations, new implementations may use the NTP
reserved mode 6 described in Appendix B and/or private reserved mode 7
for special purposes, such as remote control and monitoring, and in such
cases the format of the packet following the first octet can be
arbitrary. While there is no guarantee that different implementations
can interoperate using private reserved mode 7, it is recommended that
vanilla ASCII format be used whenever possible.

3.

Version 1 does not support authentication. The key identifiers,
cryptographic keys and procedures described in Appendix C are new to
Version 2 and continued in Version 3, along with the corresponding
variables, procedures and authenticator fields. In the NTP message
described in Appendix A and NTP control message described in Appendix B
the format and contents of the header fields are independent of the
authentication mechanism and the authenticator itself follows the header
fields, so that previous versions will ignore the authenticator.

4.

In Version 1 the total dispersion (pkt.rootdispersion) field of the NTP
header was called the estimated drift rate, but not used in the protocol
or timekeeping procedures. Implementations of the Version-1 protocol
typically set this field to the current value of the skew-compensation
register, which is a signed quantity. In a Version 2 implementation
apparent large values in this field may affect the order considered in
the clock-selection procedure. Version-2 and Version-3 implementations
interoperating with older implementations should assume this field is
zero, regardless of its actual contents.

5.

Version 2 and Version 3 incorporate several sanity checks designed to
avoid disruptions due to unsynchronized, duplicate or bogus timestamp
information. The checks in Version 3 are specifically designed to detect
lost or duplicate packets and resist invalid timestamps. The leap-
indicator bits are set to show the unsynchronized state if updates are
not received from a reference source for a considerable time or if the

reference source has not received updates for a considerable time. Some
Version-1 implementations could claim valid synchronization indefinitely
following loss of the reference source.

6.

The clock-selection procedure of Version 2 was considerably refined as
the result of accumulated experience with the Version-1 implementation.
Additional sanity checks are included for authentication, range bounds
and to avoid use of very old data. The candidate list is sorted twice,
once to select a relatively few robust candidates from a potentially
large population of unruly peers and again to order the resulting list
by measurement quality. As in Version 1, The final selection procedure
repeatedly casts out outlyers on the basis of weighted dispersion.

7.

The local-clock procedure of Version 2 were considerably improved over
Version 1 as the result of analysis, simulation and experience. Checks
have been added to warn that the oscillator has gone too long without
update from a reference source. The compliance register has been added
to improve frequency stability to the order of a millisecond per day.
The various parameters were retuned for optimum loop stability using
measured data over typical Internet paths and with typical local-clock
hardware. In version 3 the phase-lock loop model was further refined to
provide an adaptive-bandwidth feature that automatically adjusts for the
inherent stabilities of the reference clock and local clock while
providing optimum loop stability in each case.

8.

Problems in the timekeeping calculations of Version 1 with high-speed
LANs were found and corrected in Version 2. These were caused by jitter
due to small differences in clock rates and different precisions between
the peers. Subtle bugs in the Version-1 reachability and polling-rate
control were found and corrected. The peer.valid and sys.hold variables
were added to avoid instabilities when the reference source changes
rapidly due to large dispersive delays under conditions of severe
network congestion. The peer.config, peer.authenable and peer.authentic
bits were added to control special features and simplify configuration.

9.

In Version 3 The local-clock algorithm has been overhauled to improve
stability and accuracy. Appendix G presents a detailed mathematical
model and design example which has been refined with the aid of
feedback-control analysis and extensive simulation using data collected
over ordinary Internet paths. Section 5 of RFC-1119 on the NTP local
clock has been completely rewritten to describe the new algorithm. Since
the new algorithm can result in message rates far below the old ones, it

is highly recommended that they be used in new implementations. Note
that this algorithm is not integral to the NTP protocol specification
itself and its use does not affect interoperability with previous
versions or existing implementations; however, in order to insure
overall NTP subnet stability in the Internet, it is essential that the
local-clock characteristics of all NTP time servers conform to the
analytical models presented previously and in this document.

10.

In Version 3 a new algorithm to combine the offsets of a number of peer
time servers is presented in Appendix F. This algorithm is modelled on
those used by national standards laboratories to combine the weighted
offsets from a number of standard clocks to construct a synthetic
laboratory timescale more accurate than that of any clock separately. It
can be used in an NTP implementation to improve accuracy and stability
and reduce errors due to asymmetric paths in the Internet. The new
algorithm has been simulated using data collected over ordinary Internet
paths and, along with the new local-clock algorithm, implemented and
tested in the Fuzzball time servers now running in the Internet. Note
that this algorithm is not integral to the NTP protocol specification
itself and its use does not affect interoperability with previous
versions or existing implementations.

11.

Several inconsistencies and minor errors in previous versions have been
corrected in Version 3. The description of the procedures has been
rewritten in pseudo-code augmented by English commentary for clarity and
to avoid ambiguity. Appendix I has been added to illustrate C-language
implementations of the various filtering and selection algorithms
suggested for NTP. Additional information is included in Section 5 and
in Appendix E, which includes the tutorial material formerly included in
Section 2 of RFC-1119, as well as much new material clarifying the
interpretation of timescales and leap seconds.

12.

Minor changes have been made in the Version-3 local-clock algorithms to
avoid problems observed when leap seconds are introduced in the UTC
timescale and also to support an auxiliary precision oscillator, such as
a cesium clock or timing receiver, as a precision timebase. In addition,
changes were made to some procedures described in Section 3 and in the
clock-filter and clock-selection procedures described in Section 4.
While these changes were made to correct minor bugs found as the result
of experience and are recommended for new implementations, they do not
affect interoperability with previous versions or existing
implementations in other than minor ways (at least until the next leap
second).

13.

In Version 3 changes were made to the way delay, offset and dispersion
are defined, calculated and processed in order to reliably bound the
errors inherent in the time-transfer procedures. In particular, the
error accumulations were moved from the delay computation to the
dispersion computation and both included in the clock filter and
selection procedures. The clock-selection procedure was modified to
remove the first of the two sorting/discarding steps and replace with an
algorithm first proposed by Marzullo and later incorporated in the
Digital Time Service. These changes do not significantly affect the
ordinary operation of or compatibility with various versions of NTP, but
they do provide the basis for formal statements of correctness as
described in Appendix H.

Appendix E. The NTP Timescale and its Chronometry

Introduction

Following is an extended discussion on computer network chronometry,
which is the precise determination of computer time and frequency
relative to international standards and the determination of
conventional civil time and date according to the modern calendar. It
describes the methods conventionally used to establish civil time and
date and the various timescales now in use. In particular, it
characterizes the Network Time Protocol (NTP) timescale relative to the
Coordinated Universal Time (UTC) timescale, and establishes the precise
interpretation of UTC leap seconds in NTP.

In the following discussion the terms time, oscillator, clock, epoch,
calendar, date and timescale are used in a technical sense. Strictly
speaking, the time of an event is an abstraction which determines the
ordering of events in some given frame of reference. An oscillator is a
generator capable of precise frequency (relative to the given frame of
reference) to a specified tolerance. A clock is an oscillator together
with a counter which records the (fractional) number of cycles since
being initialized with a given value at a given time. The value of the
counter at any given time is called its epoch at that time. In general,
epoches are not continuous and depend on the precision of the counter.

A calendar is a mapping from epoch in some frame of reference to the
times and dates used in everyday life. Since multiple calendars are in
use today and sometimes disagree on the dating of the same events in the
past, the chronometry of past and present events is an art practiced by
historians. One of the goals of this discussion is to provide a standard
chronometry for precision dating of present and future events in a
global networking community. To synchronize frequency means to adjust
the oscillators in the network to run at the same frequency, to
synchronize time means to set the clocks so that all agree at a
particular epoch with respect to UTC, as provided by international

standards, and to synchronize clocks means to synchronize them in both
frequency and time.

In order to synchronize clocks, there must be some way to directly or
indirectly compare them in time and frequency. The ultimate frame of
reference for our world consists of the cosmic oscillators: the Sun,
Moon and other galactic orbiters. Since the frequencies of these
oscillators are relatively unstable and not known exactly, the ultimate
reference standard oscillator has been chosen by international agreement
as a synthesis of many observations of an atomic transition of exquisite
stability. The epoches of each heavenly and Earthbound oscillator
defines a distinctive timescale, not necessarily always continuous,
relative to the standard oscillator. Another goal of this presentation
is to describe a standard chronometry to rationalize conventional
computer time and UTC; in particular, how to handle leap seconds.

Primary Frequency and Time Standards

A primary frequency standard is an oscillator that can maintain
extremely precise frequency relative to a physical phenomenon, such as a
transition in the orbital states of an electron. Presently available
atomic oscillators are based on the transitions of the hydrogen, cesium
and rubidium atoms. Table 7<$&tab7> shows the characteristics for
typical oscillators of these types compared with those for various types
of quartz-crystal oscillators found in electronic equipment. For reasons
of cost and robustness cesium oscillators are used worldwide for
national primary frequency standards. On the other hand, local clocks
used in computing equipment almost always are designed with
uncompensated crystal oscillators.

For the three atomic oscillators listed in Table 7 the drift/aging
column shows the maximum offset per day from nominal standard frequency
due to systematic mechanical and electrical characteristics. In the case
of crystal oscillators this offset is not constant, which results in a
gradual change in frequency with time, called aging. Even if a crystal
oscillator is temperature compensated by some means, it must be
periodically compared to a primary standard in order to maintain the
highest accuracy. For all types of oscillators the stability column
shows the maximum variation in frequency per day due to circuit noise
and environmental factors.

As the telephone networks of the world are evolving rapidly to digital
technology, consideration should be given to the methods used for
frequency synchronization in digital networks. A network of clocks in
which each oscillator is phase-locked to a single frequency standard is
called isochronous, while a network in which some oscillators are phase-
locked to different master oscillators, but with the master oscillators
closely synchronized in frequency (not necessarily phase locked), to a
single frequency standard is called plesiochronous. In plesiochronous
systems the phase of some oscillators can slip relative to others and

cause occasional data errors in synchronous transmission systems.

The industry has agreed on a classification of clock oscillators as a
function of minimum accuracy, minimum stability and other factors
[ALL74a]. There are three factors which determine the classification:
stability, jitter and wander. Stability refers to the systematic
variation of frequency with time and is synonymous with aging, drift,
trends, etc. Jitter (also called timing jitter) refers to short-term
variations in frequency with components greater than 10 Hz, while wander
refers to long-term variations in frequency with components less than 10
Hz. The classification determines the oscillator stratum (not to be
confused with the NTP stratum), with the more accurate oscillators
assigned the lower strata and less accurate oscillators the higher
strata:

@Z_TBL_BEG = COLUMNS(3), DIMENSION(IN), COLWIDTHS(E1,E2,E2),
WIDTH(5.0000), ABOVE(.1670), BELOW(.0830), HGUTTER(.3330),
BOX(Z_SINGLE), KEEP(ON), ALIGN(CT), L1(R1C0..R1C3)

@Z_TBL_BODY = TABLE CENTER, TABLE HEADER, TABLE HEADER

Stratum, Min Accuracy (per day), Min Stability (per day)

@Z_TBL_BODY = TABLE CENTER, TABLE TEXT, TABLE TEXT

1, 1 x 10-11, not specified

2, 1.6 x 10-8, 1 x 10-10

3, 4.6 x 10-6, 3.7 x 10-7

@Z_TBL_BODY = TABLE CENTER, TABLE HEADER, TABLE HEADER

4, 3.2 x 10-5, not specified

@Z_TBL_END =

The construction, operation and maintenance of stratum-one oscillators
is assumed to be consistent with national standards and often includes
cesium oscillators or precision crystal oscillators synchronized via
LORAN-C to national standards. Stratum-two oscillators represent the
stability required for interexchange toll switches such as the AT&T 4ESS
and interexchange digital cross-connect systems, while stratum-three
oscillators represent the stability required for exchange switches such
as the AT&T 5ESS and local cross-connect systems. Stratum-four
oscillators represent the stability required for digital channel-banks
and PBX systems.

Time and Frequency Dissemination

In order that atomic and civil time can be coordinated throughout the
world, national administrations operate primary time and frequency
standards and coordinate them cooperatively by observing various radio
broadcasts and through occasional use of portable atomic clocks. Most
seafaring nations of the world operate some sort of broadcast time
service for the purpose of calibrating chronographs, which are used in
conjunction with ephemeris data to determine navigational position. In
many countries the service is primitive and limited to seconds-pips
broadcast by marine communication stations at certain hours. For
instance, a chronograph error of one second represents a longitudinal
position error of about 0.23 nautical mile at the Equator.

The U.S. National Institute of Standards and Technology (NIST - formerly
National Bureau of Standards) operates three radio services for the
dissemination of primary time and frequency information. One of these
uses high-frequency (HF or CCIR band 7) transmissions on frequencies of
2.5, 5, 10, 15 and 20 MHz from Fort Collins, CO (WWV), and Kauai, HI
(WWVH). Signal propagation is usually by reflection from the upper
ionospheric layers, which vary in height and composition throughout the
day and season and result in unpredictable delay variations at the
receiver. The timecode is transmitted over a 60-second interval at a
data rate of 1 bps using a 100-Hz subcarrier on the broadcast signal.
The timecode information includes UTC time-day information, but does not
currently include year or leap-second warning. While these transmissions
and those of Canada from Ottawa, Ontario (CHU), and other countries can
be received over large areas in the western hemisphere, reliable
frequency comparisons can be made only to the order of 10-7 and time
accuracies are limited to the order of a millisecond [BLA74]. Radio
clocks which operate with these transmissions include the Traconex 1020,
which provides accuracies to about ten milliseconds and is priced in the
$1,500 range.

A second service operated by NIST uses low-frequency (LF or CCIR band 5)
transmissions on 60 kHz from Boulder, CO (WWVB), and can be received
over the continental U.S. and adjacent coastal areas. Signal propagation
is via the lower ionospheric layers, which are relatively stable and
have predictable diurnal variations in height. The timecode is
transmitted over a 60-second interval at a rate of 1 pps using periodic
reductions in carrier power. With appropriate receiving and averaging
techniques and corrections for diurnal and seasonal propagation effects,
frequency comparisons to within 10-11 are possible and time accuracies
of from a few to 50 microseconds can be obtained [BLA74]. Some countries
in western Europe operate similar services which use transmissions on 60
kHz from Rugby, U.K. (MSF), and on 77.5 kHz from Mainflingen, West
Germany (DCF77). The timecode information includes UTC time-day-year
information and leap-second warning. Radio clocks which operate with
these transmissions include the Spectracom 8170 and Kinemetrics/TrueTime
60-DC and LF-DC, which provide accuracies to a millisecond or less and
are priced in the $2,500 range. However, these receivers do not extract
the year information and leap-second warning.

The third service operated by NIST uses ultra-high frequency (UHF or
CCIR band 9) transmissions on about 468 MHz from the Geosynchronous
Orbit Environmental Satellites (GOES), three of which cover the western
hemisphere. The timecode is interleaved with messages used to
interrogate remote sensors and consists of 60 4-bit binary-coded decimal
words transmitted over an interval of 30 seconds. The timecode
information includes UTC time-day-year information and leap-second
warning. Radio clocks which operate with these transmissions include the
Kinemetrics/TrueTime 468-DC, which provides accuracies to 0.5 ms and is
priced in the $6,000 range. However, this receiver does not extract the
year information and leap-second warning.

The U.S. Department of Defense is developing the Global Positioning
System (GPS) for worldwide precision navigation. This system will
eventually provide 24-hour worldwide coverage using a constellation of
24 satellites in 12-hour orbits. For time-transfer applications GPS has
a potential accuracy in the order of a few nanoseconds; however, various
considerations of defense policy may limit accuracy to hundreds of
nanoseconds [VAN84]. The timecode information includes GPS time and UTC
correction; however, there appears to be no leap-second warning. Radio
clocks which operate with these transmissions include the
Kinemetrics/TrueTime GPS-DC, which provides accuracies to 200 <$Emu>s
and is priced in the $12,000 range. However, since only about half the
satellites have been launched, expensive rubidium or quartz oscillators
are necessary to preserve accuracy during outages. Also, since this is a
single-channel receiver, it must be supplied with geographic coordinates
within a degree from an external source before operation begins.

The U.S. Coast Guard, along with agencies of other countries, has
operated the LORAN-C [FRA82] radionavigation system for many years. It
currently provides time-transfer accuracies of less than a microsecond
and eventually may achieve 100 ns within the ground-wave coverage area
of a few hundred kilometers from the transmitter. Beyond the ground wave
area signal propagation is via the lower ionospheric layers, which
decreases accuracies to the order of 50 us. With the recent addition of
the Mid-Continent Chain, the deployment of LORAN-C transmitters now
provides complete coverage of the U.S. LORAN-C timing receivers, such as
the Austron 2000, are specialized and extremely expensive (up to
$20,000). They are used primarily to monitor local cesium clocks and are
not suited for unattended, automatic operation. While the LORAN-C system
provides a highly accurate frequency and time reference within the
ground wave area, there is no timecode modulation, so the receiver must
be supplied with UTC time to within a few tens of seconds from an
external source before operation begins.

The OMEGA [VAS78] radionavigation system operated by the U.S. Navy and
other countries consists of eight very-low-frequency (VLF or CCIR band
4) transmitters operating on frequencies from 10.2 to 13.1 kHz and
providing 24-hour worldwide coverage. With appropriate receiving and

averaging techniques and corrections for propagation effects, frequency
comparisons and time accuracies are comparable to the LF systems, but
with worldwide coverage [BLA74]. Radio clocks which operate with these
transmissions include the Kinemetrics/TrueTime OM-DC, which provides
accuracies to 1 ms and is priced in the $3,500 range. While the OMEGA
system provides a highly accurate frequency reference, there is no
timecode modulation, so the receiver must be supplied with geographic
coordinates within a degree and UTC time within five seconds from an
external source before operation begins. There are several other VLF
services intended primarily for worldwide data communications with
characteristics similar to OMEGA. These services can be used in a manner
similar to OMEGA, but this requires specialized techniques not suited
for unattended, automatic operation.

Note that not all transmission formats used by NIST radio broadcast
services [NBS79] and no currently available radio clocks include
provisions for year information and leap-second warning. 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 the NTP specification. The protocol is
designed so that these bits can be set manually or by the radio timecode
at the primary time servers and then automatically distributed
throughout the synchronization subnet to all other time servers.
Calendar Systems

The calendar systems used in the ancient world reflect the agricultural,
political and ritual needs characteristic of the societies in which they
flourished. Astronomical observations to establish the winter and summer
solstices were in use three to four millennia ago. By the 14th century
BC the Shang Chinese had established the solar year as 365.25 days and
the lunar month as 29.5 days. The lunisolar calendar, in which the
ritual month is based on the Moon and the agricultural year on the Sun,
was used throughout the ancient Near East (except Egypt) and Greece from
the third millennium BC. Early calendars used either thirteen lunar
months of 28 days or twelve alternating lunar months of 29 and 30 days
and haphazard means to reconcile the 354/364-day lunar year with the
365-day vague solar year.

The ancient Egyptian lunisolar calendar had twelve 30-day lunar months,
but was guided by the seasonal appearance of the star Sirius (Sothis).
In order to reconcile this calendar with the solar year, a civil
calendar was invented by adding five intercalary days for a total of 365
days. However, in time it was observed that the civil year was about
one-fourth day shorter than the actual solar year and thus would precess
relative to it over a 1460-year cycle called the Sothic cycle. Along
with the Shang Chinese, the ancient Egyptians had thus established the
solar year at 365.25 days, or within about 11 minutes of the present
measured value. In 432 BC, about a century after the Chinese had done
so, the Greek astronomer Meton calculated there were 110 lunar months of
29 days and 125 lunar months of 30 days for a total of 235 lunar months

in 6940 solar days, or just over 19 years. The 19-year cycle, called the
Metonic cycle, established the lunar month at 29.532 solar days, or
within about two minutes of the present measured value.

The Roman republican calendar was based on a lunar year and by 50 BC was
eight weeks out of step with the solar year. Julius Caesar invited the
Alexandrian astronomer Sosigenes to redesign the calendar, which led to
the adoption in 46 BC of the Julian calendar. This calendar is based on
a year of 365 days with an intercalary day inserted every four years.
However, for the first 36 years an intercalary day was mistakenly
inserted every three years instead of every four. The result was 12
intercalary days instead of nine, and a series of corrections that was
not complete until 8 AD.

The seven-day Sumerian week was introduced only in the fourth century AD
by Emperor Constantine I. During the Roman era a 15-year census cycle,
called the Indiction cycle, was instituted for taxation purposes. The
sequence of day-names for consecutive occurrences of a particular day of
the year does not recur for 28 years, called the solar cycle. Thus, the
least common multiple of the 28-year solar cycle, 19-year Metonic cycle
and 15-year Indiction cycle results in a grand 7980-year supercycle
called the Julian Era, which began in 4713 BC. A particular combination
of the day of the week, day of the year, phase of the Moon and round of
the census will recur beginning in 3268 AD.

By 1545 the discrepancy in the Julian year relative to the solar year
had accumulated to ten days. In 1582, following suggestions by the
astronomers Christopher Clavius and Luigi Lilio, Pope Gregory XIII
issued a papal bull which decreed, among other things, that the solar
year would consist of 365.2422 days. In order to more closely
approximate the new value, only those centennial years divisible by 400
would be leap years, while the remaining centennial years would not,
making the actual value 365.2425, or within about 26 seconds of the
current measured value. Since the beginning of the Common Era and prior
to 1990 there were 474 intercalary days inserted in the Julian calendar,
but 14 of these were removed in the Gregorian calendar. While the
Gregorian calendar is in use throughout most of the world today, some
countries did not adopt it until early in the twentieth century.
While it remains a fascinating field for time historians, the above
narrative provides conclusive evidence that conjugating calendar dates
of significant events and assigning NTP timestamps to them is
approximate at best. In principle, reliable dating of such events
requires only an accurate count of the days relative to some globally
alarming event, such as a comet passage or supernova explosion; however,
only historically persistent and politically stable societies, such as
the ancient Chinese and Egyptian, and especially the classic Maya,
possessed the means and will to do so.

The Modified Julian Day System

In order to measure the span of the universe or the decay of the proton,
it is necessary to have a standard day-numbering plan. Accordingly, the
International Astronomical Union has adopted the use of the standard
second and Julian Day Number (JDN) to date cosmological events and
related phenomena. The standard day consists of 86,400 standard seconds,
where time is expressed as a fraction of the whole day, and the standard
year consists of 365.25 standard days.

In the scheme devised in 1583 by the French scholar Joseph Julius
Scaliger and named after his father, Julius Caesar Scaliger, JDN 0.0
corresponds to 12h (noon) on the first day of the Julian Era, 1 January
4713 BC. The years prior to the Common Era (BC) are reckoned according
to the Julian calendar, while the years of the Common Era (AD) are
reckoned according to the Gregorian calendar. Since 1 January 1 AD in
the Gregorian calendar corresponds to 3 January 1 in the Julian calendar
[DER90], JDN 1,721,426.0 corresponds to 12h on the first day of the
Common Era, 1 January 1 AD. The Modified Julian Date (MJD), which is
sometimes used to represent dates near our own era in conventional time
and with fewer digits, is defined as MJD = JD <196> 2,400,000.5.
Following the convention that our century began at 0h on 1 January 1900,
at which time the tropical year was already 12h old, that eclectic
instant corresponds to MJD 15,020.0. Thus, the Julian timescale ticks in
standard (atomic) 365.25-day centuries and was set to a given value at
the approximate epoch of a cosmic event which apparently synchronized
the entire human community, the origin of the Common Era.

Determination of Frequency

For many years the most important use of time and frequency information
was for worldwide navigation and space science, which depend on
astronomical observations of the Sun, Moon and stars [JOR85]. Sidereal
time is based on the transit of stars across the celestial meridian of
an observer. The mean sidereal day is 23 hours, 56 minutes and 4.09
seconds, but varies about <F128M>?<F255D>30 ms throughout the year due
to polar wandering and orbit variations. Ephemeris time is based on
tables with which a standard time interval such as the tropical year -
one complete revolution of the Earth around the Sun - can be determined
through observations of the Sun, Moon and planets. In 1958 the standard
second was defined as 1/31,556,925.9747 of the tropical year that began
this century. On this scale the tropical year is 365.2421987 days and
the lunar month - one complete revolution of the Moon around the Earth -
is 29.53059 days; however, the actual tropical year can be determined
only to an accuracy of about 50 ms and has been increasing by about 5.3
ms per year.

Of the three heavenly oscillators readily apparent to ancient mariners
and astronomers - the Earth rotation about its axis, the Earth
revolution around the Sun and the Moon revolution around the Earth -
none of the three have the intrinsic stability, relative to modern
technology, to serve as a standard reference oscillator. In 1967 the

standard second was redefined as <169>9,192,631,770 periods of the
radiation corresponding to the transition between the two hyperfine
levels of the ground state of the cesium-133 atom.<170> Since 1972 the
time and frequency standards of the world have been based on
International Atomic Time (TAI), which is defined and maintained using
multiple cesium-beam oscillators to an accuracy of a few parts in 1013,
or better than a microsecond per day. Note that, while this provides an
extraordinarily precise timescale, it does not necessarily agree with
conventional solar time and may not in fact even be absolutely uniform,
unless subtle atomic conspiracies can be ruled out.

Determination of Time and Leap Seconds

The International Bureau of Weights and Measures (IBWM) uses
astronomical observations provided by the U.S. Naval Observatory and
other observatories to determine UTC. Starting from apparent mean solar
time as observed, the UT0 timescale is determined using corrections for
Earth orbit and inclination (the Equation of Time, as used by sundials),
the UT1 (navigator's) timescale by adding corrections for polar
migration and the UT2 timescale by adding corrections for known
periodicity variations. While standard frequencies are based on TAI,
conventional civil time is based on UT1, which is presently slowing
relative to TAI by a fraction of a second per year. When the magnitude
of correction approaches 0.7 second, a leap second is inserted or
deleted in the TAI timescale on the last day of June or December.

For the most precise coordination and timestamping of events since 1972,
it is necessary to know when leap seconds are implemented in UTC and how
the seconds are numbered. As specified in CCIR Report 517, which is
reproduced in [BLA74], a leap second is inserted following second
23:59:59 on the last day of June or December and becomes second 23:59:60
of that day. A leap second would be deleted by omitting second 23:59:59
on one of these days, although this has never happened. Leap seconds
were inserted prior to 1 January 1991 on the occasions listed in Table
8<$&tab8> (courtesy U.S. Naval Observatory). Published IBWM corrections
consist not only of leap seconds, which result in step discontinuities
relative to TAI, but 100-ms UT1 adjustments called DUT1, which provide
increased accuracy for navigation and space science.

Note that the NTP time column actually shows the epoch following the
last second of the day given in the UTC date and MJD columns (except for
the first line), which is the precise epoch of insertion. The offset
column shows the cumulative seconds offset between the uncoordinated
(Julian) timescale and the UTC timescale; that is, the number of seconds
to add to the Julian clock in order to maintain nominal agreement with
the UTC clock. Finally, note that the epoch of insertion is relative to
the timescale immediately prior to that epoch; e.g., the epoch of the 31
December 90 insertion is determined on the timescale in effect following
the 31 December 1990 insertion, which means the actual insertion
relative to the Julian clock is fourteen seconds later than the apparent

time on the UTC timescale.

The UTC timescale thus ticks in standard (atomic) seconds and was set to
the value 0h MJD 41,317.0 at the epoch determined by astronomical
observation to be 0h on 1 January 1972 according to the Gregorian
calendar; that is, the inaugural tick of the UTC Era. In fact, the
inaugural tick which synchronized the cosmic oscillators, Julian clock,
UTC clock and Gregorian calendar forevermore was displaced about ten
seconds from the civil clock then in use, while the GPS clock is ahead
of the UTC clock by six seconds in late 1990. Subsequently, the UTC
clock has marched backward relative to the Julian timescale exactly one
second on scheduled occasions at monumental epoches embedded in the
institutional memory of our civilization. Note in passing that leap-
second adjustments affect the number of seconds per day and thus the
number of seconds per year. Apparently, should we choose to worry about
it, the UTC clock, Julian clock and various cosmic clocks will
inexorably drift apart with time until rationalized by some future papal
bull.

The NTP Timescale and Reckoning with UTC
The NTP timescale is based on the UTC timescale, but not necessarily
always coincident with it. At 0h on 1 January 1972 (MJD 41,317.0), the
first tick of the UTC Era, the NTP clock was set to 2,272,060,800,
representing the number of standard seconds since 0h on 1 January 1900
(MJD 15,020.0). The insertion of leap seconds in UTC and subsequently
into NTP does not affect the UTC or NTP oscillator, only the conversion
to conventional civil UTC time. However, since the only institutional
memory available to NTP are the UTC timecode broadcast services, the NTP
timescale is in effect reset to UTC as each timecode is received. Thus,
when a leap second is inserted in UTC and subsequently in NTP, knowledge
of all previous leap seconds is lost.

Another way to describe this is to say there are as many NTP timescales
as historic leap seconds. In effect, a new timescale is established
after each new leap second. Thus, all previous leap seconds, not to
mention the apparent origin of the timescale itself, lurch backward one
second as each new timescale is established. If a clock synchronized to
NTP in 1990 was used to establish the UTC epoch of an event that
occurred in early 1972 without correction, the event would appear
fifteen seconds late relative to UTC. However, NTP primary time servers
resolve the epoch using the broadcast timecode, so that the NTP clock is
set to the broadcast value on the current timescale. As a result, for
the most precise determination of epoch relative to the historic UTC
clock, the user must subtract from the apparent NTP epoch the offsets
shown in Table 8 at the relative epoches shown. This is a feature of
almost all present day time-distribution mechanisms.

The chronometry involved can be illustrated with the help of Figure 8,
which shows the details of seconds numbering just before, during and
after the last scheduled leap insertion at 23:59:59 on 31 December 1989.

Notice the NTP leap bits are set on the day prior to insertion, as
indicated by the <169>+<170> symbols on the figure. Since this makes the
day one second longer than usual, the NTP day rollover will not occur
until the end of the first occurrence of second 800. The UTC time
conversion routines must notice the apparent time and the leap bits and
handle the timescale conversions accordingly. Immediately after the leap
insertion both timescales resume ticking the seconds as if the leap had
never happened. The chronometric correspondence between the UTC and NTP
timescales continues, but NTP has forgotten about all past leap
insertions. In NTP chronometric determination of UTC time intervals
spanning leap seconds will thus be in error, unless the exact times of
insertion are known.

It is possible that individual systems may use internal data formats
other than the NTP timestamp format, which is represented in seconds to
a precision of about 200 picoseconds; however, a persuasive argument
exists to use a two-part representation, one part for whole days (MJD or
some fixed offset from it) and the other for the seconds (or some scaled
value, such as milliseconds). This not only facilitates conversion
between NTP and conventional civil time, but makes the insertion of leap
seconds much easier. All that is required is to change the modulus of
the seconds counter, which on overflow increments the day counter. This
design insures that continuity of the timescale is assured, even if
outside synchronization is lost before, during or after leap-second
insertion. Since timestamp data are unaffected, synchronization is
assured, even if timestamp data are in flight at the instant and
originated before or at that instant.

Appendix F. The NTP Clock-Combining Algorithm

Introduction

A common problem in synchronization subnets is systematic time-offset
errors resulting from asymmetric transmission paths, where the networks
or transmission media in one direction are substantially different from
the other. The errors can range from microseconds on high-speed ring
networks to large fractions of a second on satellite/landline paths. It
has been found experimentally that these errors can be considerably
reduced by combining the apparent offsets of a number of time servers to
produce a more accurate working offset. Following is a description of
the combining method used in the NTP implementation for the Fuzzball
[MIL88b]. The method is similar to that used by national standards
laboratories to determine a synthetic laboratory timescale from an
ensemble of cesium clocks [ALL74b]. These procedures are optional and
not required in a conforming NTP implementation.

In the following description 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.

Determining Time and Frequency

Figure 9<$&fig9> shows the overall organization of the NTP time-server
model. Timestamps exchanged with possibly many other subnet peers are
used to determine individual roundtrip delays and clock offsets relative
to each peer as described in the NTP specification. As shown in the
figure, the computed delays and offsets are processed by the clock
filter to reduce incidental timing noise and the most accurate and
reliable subset determined by the clock-selection algorithm. The
resulting offsets of this subset are first combined as described below
and then processed by the phase-locked loop (PLL). In the PLL the
combined effects of the filtering, selection and combining operations is
to produce a phase-correction term. This is processed by the loop filter
to control the local clock, which functions as a voltage-controlled
oscillator (VCO). The VCO furnishes the timing (phase) reference to
produce the timestamps used in all calculations.

Clock Modelling

The International Standard (SI) definition of time interval is in terms
of the standard second: <169>the duration of 9,192,631,770 periods of
the radiation corresponding to the transition between the two hyperfine
levels of the ground state of the cesium-133 atom.<170> Let u represent
the standard unit of time interval so defined and <$Ev~=~1 over u> be
the standard unit of frequency. The epoch, denoted by t, is defined as
the reading of a counter that runs at frequency v and began counting at
some agreed initial epoch t0, which defines the standard or absolute
timescale. For the purposes of the following analysis, the epoch of the
standard timescale, as well as the time indicated by a clock will be
considered continuous. In practice, time is determined relative to a
clock constructed from an atomic oscillator and system of
counter/dividers, which defines a timescale associated with that
particular oscillator. Standard time and frequency are then determined
from an ensemble of such timescales and algorithms designed to combine
them to produce a composite timescale approximating the standard
timescale.

Let <$ET(t)> be the time displayed by a clock at epoch t relative to the
standard timescale:

<$ET(t)~=~1/2 D(t sub 0 )[t~-~t sub 0 ] sup 2~+~R(t sub 0 )[t~-~t sub 0
]~ +~T(t sub 0 )~+~x(t)> ,

where <$ED(t sub 0 )> is the fractional frequency drift per unit time,

<$ER(t sub 0 )> the frequency and <$ET(t sub 0 )> the time at some
previous epoch t0. In the usual stationary model these quantities can be
assumed constant or changing slowly with epoch. The random nature of the
clock is characterized by <$Ex(t)>, which represents the random noise
(jitter) relative to the standard timescale. In the usual analysis the
second-order term <$ED(t sub 0 )> is ignored and the noise term <$Ex(t)>
modelled as a normal distribution with predictable spectral density or
autocorrelation function.

The probability density function of time offset <$Eroman p (t~-~T(t))>
usually appears as a bell-shaped curve centered somewhere near zero. The
width and general shape of the curve are determined by <$Ex(t)>, which
depends on the oscillator precision and jitter characteristics, as well
as the measurement system and its transmission paths. Beginning at epoch
t0 the offset is set to zero, following which the bell creeps either to
the left or right, depending on the value of <$ER(t sub 0 )> and
accelerates depending on the value of <$ED(t sub 0 )>.

Development of a Composite Timescale

Now consider the time offsets of a number of real clocks connected by
real networks. A display of the offsets of all clocks relative to the
standard timescale will appear as a system of bell-shaped curves slowly
precessing relative to each other, but with some further away from
nominal zero than others. The bells will normally be scattered over the
offset space, more or less close to each other, with some overlapping
and some not. The problem is to estimate the true offset relative to the
standard timescale from a system of offsets collected routinely between
the clocks.

A composite timescale can be determined from a sequence of offsets
measured between the n clocks of an ensemble at nominal intervals
<$Etau>. Let <$ER sub i (t sub 0 )> be the frequency and <$ET sub i (t
sub 0 )> the time of the ith clock at epoch t0 relative to the standard
timescale and let <169>^<170> designate the associated estimates. Then,
an estimator for Ti computed at t0 for epoch <$Et sub 0~+~tau> is

<$ET hat sub i ( t sub 0~+~ tau )~=~R hat sub i (t sub 0 ) tau ~+~T sub
i (t sub 0 )> ,

neglecting second-order terms. Consider a set of n independent time-
offset measurements made between the clocks at epoch <$Et sub 0 ~+~ tau>
and let the offset between clock i and clock j at that epoch be <$ET sub
ij (t sub 0~+~ tau )>, defined as

<$ET sub ij (t sub 0~+~ tau )~==~T sub i (t sub 0~+~ tau )~-~T sub j (t
sub 0~+~ tau )> .

Note that <$ET sub ij~=~- T sub ji> and <$ET sub ii~=~0>. Let <$Ew sub i
( tau )> be a previously determined weight factor associated with the

ith clock for the nominal interval <$Etau>. The basis for new estimates
at epoch <$Et sub 0~+~ tau > is

<$ET sub j (t sub 0~+~tau )~=~sum from {i=1} to n w sub i ( tau )[ T hat
sub i (t sub 0~+~tau )~+~T sub ji (t sub 0~+~tau )].>

That is, the apparent time indicated by the jth clock is a weighted
average of the estimated time of each clock at epoch <$Et sub 0 ~+~ tau>
plus the time offset measured between the jth clock and that clock at
epoch <$Et sub 0 ~+~ tau>.

An intuitive grasp of the behavior of this algorithm can be gained with
the aid of a few examples. For instance, if <$Ew sub i ( tau )> is unity
for the ith clock and zero for all others, the apparent time for each of
the other clocks is simply the estimated time <$ET hat sub i (t sub
0~+~tau )>. If <$Ew sub i ( tau )> is zero for the ith clock, that clock
can never affect any other clock and its apparent time is determined
entirely from the other clocks. If <$Ew sub i ( tau )~=~1 / n> for all
i, the apparent time of the ith clock is equal to the average of the
time estimates computed at t0 plus the average of the time offsets
measured to all other clocks. Finally, in a system with two clocks and
<$Ew sub i ( tau )~=~1 / 2> for each, and if the estimated time at epoch
<$Et sub 0~+~tau> is fast by 1 s for one clock and slow by 1 s for the
other, the apparent time for both clocks will coincide with the standard
timescale.

In order to establish a basis for the next interval <$Etau>, it is
necessary to update the frequency estimate <$ER hat sub i (t sub 0~+~tau
)> and weight factor <$Ew sub i ( tau )>. The average frequency assumed
for the ith clock during the previous interval <$Etau> is simply the
difference between the times at the beginning and end of the interval
divided by <$Etau>. A good estimator for <$ER sub i (t sub 0~+~tau )>
has been found to be the exponential average of these differences, which
is given by

<$ER hat sub i (t sub 0~+~tau )~=~R hat sub i (t sub 0 )~+~alpha sub i [
R hat sub i (t sub 0 )~-~{T sub i (t sub 0~+~tau )~-~T sub i (t sub 0 )}
over tau ]> ,

where <$Ealpha sub i> is an experimentally determined weight factor
which depends on the estimated frequency error of the ith clock. In
order to calculate the weight factor <$Ew sub i ( tau )>, it is
necessary to determine the expected error <$Eepsilon sub i ( tau )> for
each clock. In the following, braces <169>|<170> indicate absolute value
and brackets <169><<>><170> indicate the infinite time average. In
practice, the infinite averages are computed as exponential time
averages. An estimate of the magnitude of the unbiased error of the ith
clock accumulated over the nominal interval <$Etau> is

<$Eepsilon sub i ( tau )~=~| T hat sub i ( t sub 0~+~tau )~-~T sub i ( t