As per Relevance of the word reference, we have this rfc below:
Network Working Group D.L.
Request for Comments: 958 M/A-COM
September 1985
Network Time Protocol (NTP
Status of this
This RFC suggests a proposed protocol for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited
Table of
1.
2. Service
3. Protocol
4. State Variables and
5. Protocol
5.1. Protocol
5.2. Message
5.3. Network
5.4. Leap
6.
Appendix A. UDP Header
Appendix B. NTP Data
1.
This document describes the Network Time Protocol (NTP), a
for synchronizing a set of network clocks using a set of
clients and servers. NTP is built on the User Datagram
(UDP) [13], which provides a connectionless transport mechanism.
is evolved from the Time Protocol [7] and the ICMP Timestamp
[6] and is a suitable replacement for both
NTP provides the protocol mechanisms to synchronize time in
to precisions in the order of nanoseconds while preserving
non-ambiguous date, at least for this century. The protocol
provisions to specify the precision and estimated error of the
clock and the characteristics of the reference clock to which it
be synchronized. However, the protocol itself specifies only
data representation and message formats and does not specify
synchronizing algorithms or filtering mechanisms
Other mechanisms have been specified in the Internet protocol
to record and transmit the time at which an event takes place
including the Daytime protocol [8] and IP Timestamp option [9].
NTP is not meant to displace either of these mechanisms.
information on network time synchronization can be found in
Mills [Page 1]
RFC 958
Network Time
References at the end of this document. An earlier
protocol is discussed in [3] and synchronization algorithms in [2],
[5], [10] and [12]. Experimental results on measured roundtrip
and clock offsets in the Internet are discussed in [4] and [11].
comprehensive mathematical treatment of clock synchronization can
found in [1].
2. Service
The intent of the service for which this protocol is designed is
connect a few primary reference clocks, synchronized by wire or
to national standards, to centrally accessable resources such
gateways. These gateways would use NTP between them to cross-
the primary clocks and mitigate errors due to equipment
propagation failures. Some number of local-net hosts, serving
secondary reference clocks, would run NTP with one or more of
gateways. In order to reduce the protocol overhead, these
would redistribute time to the remaining local-net hosts. In
interest of reliability selected hosts might be equipped with
accurate but less expensive radio clocks and used for backup in
of failure of the primary and/or secondary clocks or
paths between them
In the normal configuration a subnetwork of primary and
clocks will assume a hierarchical organization with the more
clocks near the top and the less accurate below. NTP
information that can be used to organize this hierarchy on the
of precision or estimated error and even to serve as a
routing algorithm to organize the subnetwork itself. However,
NTP protocol does not include a specification of the algorithms
doing this, which is left as a topic for further study
3. Protocol
There is no provision for peer discovery, acquisition,
authentication in NTP. Data integrity is provided by the IP and
checksums. No reachability, circuit-management, duplicate-
or retransmission facilities are provided or necessary. The
can operate in a symmetric mode, in which servers and clients
indistinguishable yet maintain a small amount of state information
or in an unsymmetric mode in which servers need maintain no
state other than that contained in the client request. Moreover
only a single NTP message format is necessary, which
implementation and can be used in a variety of solicited
unsolicited polling mechanisms
In what may be the most common (unsymmetric) mode a client sends
Mills [Page 2]
RFC 958
Network Time
NTP message to one or more servers and processes the replies
received. The server interchanges addresses and ports, fills in
overwrites certain fields in the message, recalculates the
and returns it immediately. Information included in the NTP
allows each client/server peer to determine the
characteristics of its other peers, including the expected
of their clocks. Using this information each peer is able to
the best time from possibly several other clocks, update the
clock and estimate its accuracy
It should be recognized that clock synchronization requires by
nature long periods and multiple comparisons in order to
accurate timekeeping. While only a few comparisons are
adequate to maintain local time to within a second, primarily
protect against broken hardware or synchronization failure,
of hours or days and tens or hundreds of comparisons are required
maintain local time to within a few tens of milliseconds
Fortunately, the frequency of comparisons can be quite small
almost always non-intrusive to normal network operations
4. State Variables and
NTP timestamps are represented as a 64-bit fixed-point number,
seconds relative to 0000 UT on 1 January 1900. The integer part
in the first 32 bits and the fraction part in the last 32 bits,
shown in the following diagram
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Integer Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fraction Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This format allows convenient multiple-precision arithmetic
conversion to Time Protocol representation (seconds), but
complicate the conversion to ICMP Timestamp message
(milliseconds). The low-order fraction bit increments at
0.2-nanosecond intervals, so a free-running one-millisecond
will be in error only a small fraction of one part per million,
less than a second per year
In some cases a particular timestamp may not be available, such
when the protocol first starts up. In these cases the 64-bit
is set to zero, indicating the value is invalid or undefined
Mills [Page 3]
RFC 958
Network Time
Following is a description of the various data items used in
protocol. Details of packet formats are presented in the Appendices
Leap
This is a two-bit code warning of an impending leap-second to
inserted in the internationally coordinated Standard
broadcasts. A leap-second is occasionally added or
from Standard Time, which is based on atomic clocks, to
agreement with Earth rotation. When necessary, the
are notified in advance and executed at the end of the last day
the month in which notified, usually June or December. When
correction is executed the first minute of the following day
have either 59 or 61 seconds
This is a six-bit code indicating the status of the local clock
Values are assigned to indicate whether it is operating
or in one of several error states
Reference Clock
This is an eight-bit code identifying the type of reference
used to set the local clock. Values are assigned for
clocks (locally synchronized to Standard Time), secondary
(remotely synchronized via various network protocols) and
eyeball-and-wristwatch
This is a 16-bit signed integer indicating the precision of
local clock, in seconds to the nearest power of two.
instance, a 60-Hz line-frequency clock would be assigned the
-6, while a 1000-Hz crystal clock would be assigned the value -10.
Estimated
This is a 32-bit fixed-point number indicating the estimated
of the local clock at the time last set. The value is in seconds
with fraction point between bits 15 and 16, and is computed by
sender based on the reported error of the reference clock,
precision and drift rate of the local clock and the time the
clock was last set. For statistical purposes this quantity can
assumed equal to the estimated or computed standard deviation,
described in [12].
Mills [Page 4]
RFC 958
Network Time
Estimated Drift
This is a 32-bit signed fixed-point number indicating
estimated drift rate of the local clock. The value
dimensionless, with fraction point to the left of the high-
bit. While for most purposes this value can be estimated based
the hardware characteristics, it is possible to compute it
accurately, as described in [12].
Reference Clock
This is a 32-bit code identifying the particular reference clock
The interpretation of its value depends on value of
Clock Type. In the case of a primary clock locally
to Standard Time (type 1), the value is an ASCII
identifying the clock. In the case of a secondary clock
synchronized to an Internet host via NTP (type 2), the value
the 32-bit Internet address of that host. In other cases
value is undefined
Reference
This is a 64-bit timestamp established by the server or
host as the timestamp (presumably obtained from a reference clock
most recently used to update the local clock. If the local
has never been synchronized, the value is zero
Originate
This is a 64-bit timestamp established by the client host
specifying the local time at which the request departed for
service host. It will always have a nonzero value
Receive
This is a 64-bit timestamp established by the server host
specifying the local time at which the request arrived from
client host. If no request has ever arrived from the client
value is zero
Transmit
This is a 64-bit timestamp established by the server host
specifying the local time at which the reply departed for
client host. If no request has ever arrived from the client
value is zero
Mills [Page 5]
RFC 958
Network Time
5. Protocol
The intent of this document is to specify a standard for
representation and message format which can be used for a variety
synchronizing algorithms and filtering mechanisms. Accordingly,
information in this section should be considered a guide, rather
a concise specification. Nevertheless, it is expected that
standard Internet distributed timekeeping protocol with
specified synchronizing and filtering algorithms can be evolved
the information in this section
5.1. Protocol
The distinction between client and server is significant only
the way they interact in the request/response interchange.
same NTP message format is used by each peer and contains the
data relative to the other peer. In the unsymmetric mode
client periodically sends an NTP message to the server, which
responds within some interval. Usually, the server
interchanges addresses and ports, fills in the
information and sends the message right back. Servers operating
the unsymmetric mode then need retain no state information
client requests
In the symmetric mode the client/server distinction disappears
Each peer maintains a table with as many entries as active peers
each entry including a code uniquely identifying the peer (e.g
Internet address), together with status information and a copy
the Originate Timestamp and Receive Timestamp values last
from that peer. The peer periodically sends an NTP message to
of these peers including the latest copy of these timestamps.
interval between sending NTP messages is managed solely by
sending peer and is unaffected by the arrival of NTP messages
other peers
The mode assumed by a peer can be determined by inspection of
UDP Source Port and Destination Port fields (see Appendix A).
both of these fields contain the NTP service-port number 123,
peer is operating in symmetric mode. If they are different
the Destination Port field contains 123, this is a client
and the receiver is expected to reply in the manner
above. If they are different and the Source Port field
123, this is a server reply to a previously sent client request
Mills [Page 6]
RFC 958
Network Time
5.2. Message
The significant events of interest in NTP occur usually near
times the NTP messages depart and arrive the client/server.
order to maintain the highest accuracy it is important that
timestamps associated with these events be computed as close
possible to the hardware or software driver associated with
communications link and, in particular, that departure
be recomputed for each retransmission, if used at the link level
An NTP message is constructed as follows (see Appendix B).
source peer constructs the UDP header and the LI, Status
Reference Clock Type and Precision fields in the NTP data portion
Next, it determines the current synchronizing source
constructs the Type and Reference Clock Identifier fields.
its timekeeping algorithm (see [12] for examples) it
the Reference Timestamp, Estimated Error and Estimated Drift
fields. Then it copies into the Receive Timestamp and
Timestamp fields the data saved from the latest message
from the destination peer and, finally, computes the
Timestamp field
The destination peer calculates the roundtrip delay and
offset relative to the source peer as follows. Let t1, t2 and t
represent the contents of the Originate Timestamp,
Timestamp and Transmit Timestamp fields and t4 the local time
NTP message is received. Then the roundtrip delay d and
offset c is
d = (t4 - t1) - (t3 - t2) and c = (t2 - t1 + t3 - t4)/2 .
The implicit assumption in the above is that the one-way delay
statistically half the roundtrip delay and that the
drift rates of both the client and server clocks are small
close to the same value
5.3. Network
The client/server peers have an opportunity to learn a good
about each other in the NTP message exchange. For instance,
can learn about the characteristics of the other clocks and
among them the most accurate to use as reference clock,
the estimated error and drift rate and use this information
manage the dynamics of the subnetwork of clocks. An outline of
suggested mechanism is as follows
Included in the table of timestamps for each peer are
Mills [Page 7]
RFC 958
Network Time
variables to indicate the precision, as well as the
estimated delay, offset, error and drift rate of its local clock
These variables are updated for each NTP message received from
peer, after which the estimated error is periodically
on the basis of elapsed time and estimated drift rate
Assuming symmetric mode, a polling interval is established
each peer, depending upon its normal synchronization source
precision and intrinsic accuracy, which might be determined
advance or even as the result of observation. The delay
clock-offset samples obtained can be filtered
maximum-likelihood techniques and algorithms described in [12].
From time to time a local-clock correction is computed from
offset data accumulated as above, perhaps using
described in [10] and [12]. The correction causes the local
to run slightly fast or slow to the corrected time or to
instantaneously to the correct time, depending on the magnitude
the correction. See [5] and [11] for a discussion of local-
implementation models and synchronizing algorithms. Note that
expectation here is that all network clocks are maintained
these algorithms, so that manual intervention is not
required
As a byproduct of the above operations an estimate of local-
error and drift rate can be computed. Note that the magnitude
the error estimate must always be greater than that of
selected reference clock by at least the inherent precision of
local clock. It does not take a leap of imagination to see
the estimated error, delay or precision, or some combination
them, can be used as a metric for a simple min-hop-type
algorithm to organize the subnetwork so as to provide the
accurate time to all peers and to provide automatic fallback
alternate sources in case of failures
A variety of network configurations can be included in the
scenario. In the case of networks supporting a
function, for example, NTP messages can be broadcast from one
more server hosts and picked up by client hosts sharing the
cable. Since typical networks of this type have a very
propagation delay, the roundtrip-delay calculation can be
and the clients need not broadcast in return. Thus,
requirement to save per-peer timestamps is removed, so that
Receive Timestamp and Transmit Timestamp fields can be set to
and the local-clock offset becomes simply the difference
the Originate Timestamp and the local time upon arrival. In
case of long-delay satellite networks with broadcast capabilities
Mills [Page 8]
RFC 958
Network Time
an accurate measure of roundtrip delay is usually available
the channel-scheduling algorithm, so the per-peer timestamps
can be avoided
5.4. Leap
A standard mechanism to effect leap-second correction is not
part of this specification. It is expected that the
Indicator bits would be set by hand in the primary
clocks, then trickle down to all other clocks in the network
which would execute the correction at the specified time and
the bits
Mills [Page 9]
RFC 958
Network Time
6.
1. Lindsay, W.C., and A.V. Kantak. Network Synchronization
Random Signals. IEEE Trans. Comm. COM-28, 8 (August 1980),
1260-1266.
2. Mills, D.L. Time Synchronization in DCNET Hosts. DARPA
Project Report IEN-173, COMSAT Laboratories, February 1981.
3. Mills, D.L. DCNET Internet Clock Service. DARPA Network
Group Report RFC-778, COMSAT Laboratories, April 1981.
4. Mills, D.L. Internet Delay Experiments. DARPA Network
Group Report RFC-889, M/A-COM Linkabit, December 1983.
5. Mills, D.L. DCN Local-Network Protocols. DARPA Network
Group Report RFC-891, M/A-COM Linkabit, December 1983.
6. Postel, J. Internet Control Message Protocol. DARPA
Working Group Report RFC-792, USC Information Sciences Institute
September 1981.
7. Postel, J. Time Protocol. DARPA Network Working Group
RFC-868, USC Information Sciences Institute, May 1983.
8. Postel, J. Daytime Protocol. DARPA Network Working Group
RFC-867, USC Information Sciences Institute, May 1983.
9. Su, Z. A Specification of the Internet Protocol (IP)
Option. DARPA Network Working Group Report RFC-781.
International, May 1981.
10. Marzullo, K., and S. Owicki. Maintaining the Time in
Distributed System. ACM Operating Systems Review 19, 3 (
1985), 44-54.
11. Mills, D.L. Experiments in Network Clock Synchronization.
Network Working Group Report RFC-957, M/A-COM Linkabit,
1985.
12. Mills, D.L. Algorithms for Synchronizing Network Clocks.
Network Working Group Report RFC-956, M/A-COM Linkabit,
1985.
13. Postel, J. User Datagram Protocol. DARPA Network Working
Report RFC-768, USC Information Sciences Institute, August 1980.
Mills [Page 10]
RFC 958
Network Time
Appendix A. UDP Header
An NTP packet consists of the UDP header followed by the NTP
portion. The format of the UDP header and the interpretation of
fields are described in [13] and are not part of the
specification. They are shown below for completeness
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source
UDP source port number. In the case of unsymmetric mode and
client request this field is assigned by the client host,
for a server reply it is copied from the Destination Port field
the client request. In the case of symmetric mode, both
Source Port and Destination Port fields are assigned the
service-port number 123.
Destination
UDP destination port number. In the case of unsymmetric mode and
client request this field is assigned the NTP service-port
123, while for a server reply it is copied form the Source
field of the client request. In the case of symmetric mode,
the Source Port and Destination Port fields are assigned the
service-port number 123.
Length of the request or reply, including UDP header, in octets
Standard UDP checksum
Mills [Page 11]
RFC 958
Network Time
Appendix B. NTP Data
The format of the NTP data portion, which immediately follows the
header, is shown below along with a description of its fields
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | Status | Type | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Estimated Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Estimated Drift Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Clock Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64 bits) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leap Indicator (LI
Code warning of impending leap-second to be inserted at the end
the last day of the current month. Bits are coded as follows
00 no
01 +1 second (following minute has 61 seconds
10 -1 second (following minute has 59 seconds
11 reserved for future
Code indicating status of local clock. Values are defined
follows
Mills [Page 12]
RFC 958
Network Time
0 clock operating
1 carrier
2 synch
3 format
4 interface (Type 1) or link (Type 2)
(additional codes reserved for future use
Reference Clock
(Type
Code identifying the type of reference clock. Values are
as follows
0
1 primary reference (e.g. radio clock
2 secondary reference using an Internet host via
3 secondary reference using some other host or
4 eyeball-and-
(additional codes reserved for future use
Signed integer in the range +32 to -32 indicating the precision
the local clock, in seconds to the nearest power of two
Estimated
Fixed-point number indicating the estimated error of the
clock at the time last set, in seconds with fraction point
bits 15 and 16.
Estimated Drift
Signed fixed-point number indicating the estimated drift rate
the local clock, in dimensionless units with fraction point to
left of the high-order bit
Reference
Code identifying the particular reference clock. In the case
type 1 (primary reference), this is a left-justified, zero-
ASCII string identifying the clock, for example
WWVB WWVB radio clock (60 KHz
Mills [Page 13]
RFC 958
Network Time
GOES GOES satellite clock (468 HMz
WWV WWV radio clock (2.5/5/10/15/20 MHz
(and others as necessary
In the case of type 2 (secondary reference) this is the 32-
Internet address of the reference host. In other cases this
is reserved for future use and should be set to zero
Reference
Local time at which the local clock was last set or corrected
Originate
Local time at which the request departed the client host for
service host
Receive
Local time at which the request arrived at the service host
Transmit
Local time at which the reply departed the service host for
client host
Mills [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
