NETWORK TIME PROTOCOL

Network Time Protocol

Contents
Network Time Protocol................................................................................................ 1
Introduction.............................................................................................................. 2
Features of NTP......................................................................................................... 3
NTP Versions............................................................................................................. 4
Implementation of system........................................................................................ 5
References.................................................................................................................. 8

MILO DAVITKOVI 1
 Introduction
Network Time Protocol (NTP) is a networking protocol for clock synchronization between
computer systems over packet-switched, variable-latency data networks. In operation since before 1985,
NTP is one of the oldest Internet protocols in current use. NTP stands for Network Time Protocol, and it is
an Internet protocol used to synchronize the clocks of computers to some time reference.
NTP is intended to synchronize all participating computers to within a few milliseconds of
Coordinated Universal Time (UTC). It uses a modified version of Marzullo's algorithm to select accurate
time servers and is designed to mitigate the effects of variable network latency. NTP can usually maintain
time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond
accuracy in local area networks under ideal conditions. Asymmetric routes and network congestion can
cause errors of 100 ms or more.

How NTP works

The term NTP applies to both the protocol and the client/server programs that run on
computers. The programs are compiled by the user as an NTP client, NTP server, or both. In basic
terms, the NTP client initiates a time request exchange with the time server. As a result of this
exchange, the client is able to calculate the link delay and its local offset, and adjust its local clock to
match the clock at the server's computer. As a rule, six exchanges over a period of about five to 10
minutes are required to initially set the clock. Once synchronized, the client updates the clock about
once every 10 minutes, usually requiring only a single message exchange. In addition to client/server
synchronization, NTP also supports broadcast synchronization of peer computer clocks. Unfortunately,
the NTP protocol can be exploited and used for denial of service (DoS) attacks because it will reply to
a packet with a spoofed source IP address and because at least one of its built-in commands will send a
long reply to a short request.

The protocol is usually described in terms of a client-server model, but can as easily be used in
peer-to-peer relationships where both peers consider the other to be a potential time source.
Implementations send and receive timestamps using the User Datagram Protocol (UDP) on port number
123. They can also use broadcasting or multicasting, where clients passively listen to time updates after an
initial round-trip calibrating exchange. NTP supplies a warning of any impending leap second adjustment,
but no information about local time zones or daylight saving time is transmitted.

Why should Time be synchronized?

Accurate time across a network is important for many reasons; even small fractions of a second
can cause problems. For example, distributed procedures depend on coordinated times to ensure that
proper sequences are followed. Security mechanisms depend on coordinated times across the network.
File system updates carried out by a number of computers also depend on synchronized clock times. Air
traffic control systems provide a graphic illustration of the need for coordinated times, since flight paths
require very precise timing (imagine the situation if air traffic controller computer clock times were not
synchronized).
Time usually just advances. If you have communicating programs running on different computers,
time still should even advance if you switch from one computer to another. Obviously if one system is
ahead of the others, the others are behind that particular one. From the perspective of an external observer,
switching between these systems would cause time to jump forward and back, a non-desirable effect.
As a consequence, isolated networks may run their own wrong time, but as soon as you connect to
the Internet, effects will be visible. Just imagine some EMail message arrived five minutes before it was
sent, and there even was a reply two minutes before the message was sent.
Even on a single computer some applications have trouble when the time jumps backwards. For
example, database systems using transactions and crash recovery like to know the time of the last good
state. Therefore, air traffic control was one of the first applications for NTP.

Features of NTP
What are the basic features of NTP?

There exist several protocols to synchronize computer clocks, each having distinguished features.
Here is a list of NTP's features:

o NTP needs some reference clock that defines the true time to operate. All clocks are set
towards that true time. (It will not just make all systems agree on some time, but will
make them agree upon the true time as defined by some standard.)

o NTP uses UTC as reference time

o NTP is a fault-tolerant protocol that will automatically select the best of several available
time sources to synchronize to. Multiple candidates can be combined to minimize the
accumulated error. Temporarily or permanently insane time sources will be detected and
avoided.

o NTP is highly scalable: A synchronization network may consist of several reference

clocks. Each node of such a network can exchange time information either bidirectional
or unidirectional. Propagating time from one node to another forms a hierarchical graph
with reference clocks at the top.

o Having available several time sources, NTP can select the best candidates to build its
estimate of the current time. The protocol is highly accurate, using a resolution of less
 than a nanosecond (about 2-32 seconds). (The popular protocol used by rdate and defined
in [RFC 868] only uses a resolution of one second).

o Even when a network connection is temporarily unavailable, NTP can use measurements
from the past to estimate current time and error.

o For formal reasons NTP will also maintain estimates for the accuracy of the local time.

How many NTP servers are available in the Internet?

According to A Survey of the NTP Network there were at least 175,000 hosts running NTP in the
Internet. Among these there were over 300 valid stratum-1 servers. In addition there were over 20,000
servers at stratum 2, and over 80,000 servers at stratum 3.

NTP Versions

Which version of NTP should I use?

Unfortunately the answer to this question is not quite easy: Currently there are version three and
version four implementations of NTP available. The latest software release being worked on is NTPv4, but
the official Internet standard is still NTPv3. In addition, some vendors of operating systems customize and
deliver their own versions. If you rely on support, you should also consider that.

If you are worried with compatibility issues, older version clients can generally talk to newer
version servers automagically (as newer servers know how to answer the queries, hopefully), but the other
direction requires manual interference (See html/confopt.htm about the version keyword).

NTPv4 introduces some new features that you may find desirable (See Q: 4.1.9.). For example, if
you use dial-up connections, version four can increase its polling interval above one day if the clock is
stable enough. In addition the new algorithms can deal with high delay variations a bit better than the
LAN-oriented version three. On the other hand, NTPv4 uses floating point operations where NTPv3 used
integer arithmetic. This should not be a problem for current hardware, but might be an issue for older
systems without a floating point unit.

There is also a security issue with all versions probably older than 4.0.99k23 that may allow
denial of service or even unauthorized system access. Still vendors supplying older versions may have
fixed their particular version.
What's new in Version 4?
According to the NTP Version 4 Release Notes found in release.htm, the new features of version
four (as compared to version three) are:

Use of floating-point arithmetic instead of fixed-point arithmetic.

Redesigned clock discipline algorithm that improves accuracy, handling of network jitter, and
polling intervals.
Support for the nanokernel kernel implementation that provides nanosecond precision as well as
improved algorithms.
Public-Key cryptography known as autokey that avoids having common secret keys.
Automatic server discovery (manycast mode)
Fast synchronization at startup and after network failures (burst mode)
New and revised drivers for reference clocks
Support for new platforms and operating systems

Implementation of system
Background of the system
NTP uses Coordinated Universal Time (UTC) to synchronize computer clock times to a
millisecond, and sometimes to a fraction of a millisecond. UTC time is obtained using several different
methods, including radio and satellite systems. Specialized receivers are available for high-level services
such as the Global Positioning System (GPS) and the governments of some nations. However, it is not
practical or cost-effective to equip every computer with one of these receivers. Instead, computers
designated as primary time servers are outfitted with the receivers and they use protocols such as NTP to
synchronize the clock times of networked computers. Degrees of separation from the UTC source are
defined as strata. A radio clock (which receives true time from a dedicated transmitter or satellite
navigation system) is stratum-0; a computer that is directly linked to the radio clock is stratum-1; a
computer that receives its time from a stratum-1 computer is stratum-2, and so on.

NTP Timescale and Data Formats

NTP clients and servers synchronize to the Coordinated Universal Time (UTC) timescale used by
national laboratories and disseminated by radio, satellite and telephone modem. This is a global timescale
independent of geographic position. There are no provisions to correct for local time zone or daylight
savings time; however, these functions can be performed by the operating system on a per-user basis.
The UT1 timescale, upon which UTC is based, is determined by the rotation of the Earth about its
axis. The Earth rotation is gradually slowing down relative to International Atomic Time (TAI). In order to
rationalize UTC with respect to TAI, a leap second is inserted at intervals of about 18 months, as
determined by the International Earth Rotation Service (IERS). Reckoning with leap seconds in the NTP
timescale is described in the white paper The NTP Timescale and Leap Seconds.
 The historic insertions are documented in the leap-seconds.list file, which can be downloaded
from the NIST FTP servers. This file is updated at intervals not exceeding six months. Leap second
warnings are disseminated by the national laboratories in the broadcast timecode format. These warnings
are propagated from the NTP primary servers via other server to the clients by the NTP on-wire protocol.
The leap second is implemented by the operating system kernel, as described in the white paper The NTP
Timescale and Leap Seconds. Implementation details are described on the Leap Second Processing page.

Figure 1. NTP Data Formats

Figure 1 shows two NTP time formats, a 64-bit timestamp format and a 128-bit datestamp format.
The datestamp format is used internally, while the timestamp format is used in packet headers exchanged
between clients and servers. The timestamp format spans 136 years, called an era. The current era began
on 1 January 1900, while the next one begins in 2036. Details on these formats and conversions between
them are in the white paper The NTP Era and Era Numbering. However, the NTP protocol will
synchronize correctly, regardless of era, as long as the system clock is set initially within 68 years of the
correct time. Further discussion on this issue is in the white paper NTP Timestamp Calculations.
Ordinarily, these formats are not seen by application programs, which convert these NTP formats to native
Unix or Windows formats.

Architecture and Algorithms

Figure 2. NTP Daemon Processes and Algorithms

The overall organization of the NTP architecture is shown in Figure 2. It is useful in this context
to consider the implementation as both a client of upstream (lower stratum) servers and as a server for
downstream (higher stratum) clients. It includes a pair of peer/poll processes for each reference clock or
remote server used as a synchronization source. Packets are exchanged between the client and server using
the on-wire protocoldescribed in the white paper Analysis and Simulation of the NTP On-Wire Protocols.
The protocol is resistant to lost, replayed or spoofed packets.
 The poll process sends NTP packets at intervals ranging from 8 s to 36 hr. The intervals are
managed as described on the Poll Process page to maximize accuracy while minimizing network load. The
peer process receives NTP packets and performs the packet sanity tests described on the Event Messages
and Status Words page and flash status word. The flash status word reports in addition the results of
various access control and security checks described in the white paper NTP Security Analysis. A
sophisticated traffic monitoring facility described on the Rate Management and the Kiss-o'-Death
Packet page protects against denial-of-service (DoS) attacks.

Packets that fail one or more of these tests are summarily discarded. Otherwise, the peer process
runs the on-wire protocol that uses four raw timestamps: the origin timestamp T1 upon departure of the
client request, the receive timestamp T2 upon arrival at the server, the transmit timestamp T3 upon
departure of the server reply, and the destination timestamp T4 upon arrival at the client. These
timestamps, which are recorded by the rawstats option of the filegen command, are used to calculate the
clock offset and roundtrip delay samples:
offset = [(T2 - T1) + (T3 - T4)] / 2,
delay = (T4 - T1) - (T3 - T2).

In this description the transmit timestamps T1 and T3 are softstamps measured by the inline code.
Softstamps are subject to various queuing and processing delays. A more accurate measurement
uses drivestamps, as described on the NTP Interleaved Modes page. These issues along with mathematical
models are discussed in the white paper NTP Timestamp Calculations.

The offset and delay statistics for one or more peer processes are processed by a suite of
mitigation algorithms. The algorithm described on the Clock Filter Algorithm page selects the offset and
delay samples most likely to produce accurate results. Those servers that have passed the sanity tests are
declared selectable. From the selectable population the statistics are used by the algorithm described on
the Clock Select Algorithm page to determine a number of truechimers according to Byzantine agreement
and correctness principles. From the truechimer population the algorithm described on the Clock Cluster
Algorithm page determines a number of survivors on the basis of statistical clustering principles.

The algorithms described on the Mitigation Rules and the prefer Keyword page combine the
survivor offsets, designate one of them as the system peer and produces the final offset used by the
algorithm described on the Clock Discipline Algorithm page to adjust the system clock time and
frequency. The clock offset and frequency, are recorded by the loopstats option of the filegen command.
For additional details about these algorithms, see the Architecture Briefing on the Network Time
Synchronization Research Project page. For additional information on statistacl principles and
performance metrics, see the Performance Metrics page.
 References
eecis. How NTP Works. [Online]
https://www.eecis.udel.edu/~mills/ntp/html/warp.html.

ntp. What is NTP? [Online] http://www.ntp.org/ntpfaq/NTP-s-def.htm.

searchnetworking. Network-Time-Protocol. [Online]

http://searchnetworking.techtarget.com/definition/Network-Time-Protocol.

wikipedia. Network_Time_Protocol. [Online]

https://en.wikipedia.org/wiki/Network_Time_Protocol.