Through the Looking Glass
The Network Time Protocol (NTP) is three things: the NTP software program, called a daemon in Unix and a service in Windows; a protocol that exchanges time values between servers and clients; and a suite of algorithms that process the time values to advance or retard the system clock. In this topic, especially in this topic, we speak of NTP "doing something." This is rather loose terminology since the acronym NTP is a descriptive noun and uncomfortable with an action verb. More properly, it is the NTP daemon that does something and that depends on the implementation. Nevertheless, in this topic we sometimes animate the acronym.
One of the things that NTP has been "doing" is evolving in five versions over almost three decades.* With few exceptions, the last four versions are interoperable, and all can exchange time values and synchronize the system clock. However, the timekeeping quality has much improved over the versions, and many features have been added. If needed, the version is specified as NTPv3 for version 3 and NTPv4 for version 4; if not, the generic NTP is used. The current NTPv4 reference implementation, ntpd, is designed to run in a multitasking environment as an independent, self-contained program. This program sends and receives time values with each of possibly several NTP servers running elsewhere in the Internet.
This topic is organized as follows: First discussed is set of general requirements for NTP to do its job and be a good network citizen. Next is a discussion of how NTP reckons the time with respect to sources elsewhere in the Internet. The discussion continues with how the various program units fit together and operate to determine the time offset of the system clock relative to possibly several remote servers. Next a discussion of how the system clock time and frequency are adjusted to minimize the offset over time is presented. NTP can operate in several modes, such as client/server, symmetric, and broadcast, depending on the configuration. These modes and the associations that define them are discussed next. NTPv4 introduces new methods to discover servers and automatically select among them for the most precise timekeeping. The topic concludes with an overview of the security model, access controls, and system monitoring.
NTP must operate in the Internet of today with occasional server failures, traffic emergencies, route flaps, hacker attacks, and facility outages. Following is a set of assertions that have served as the developer’s road map.
1. The protocol and algorithms must perform well over a wide range of conditions and optimize the various algorithm parameters automatically for each server, network path, and computer clock. Good performance requires multiple comparisons over relatively long periods of time. For instance, while only a few measurements are usually adequate to determine local time in the Internet to within a millisecond or two, a number of measurements over several hours are required to reliably stabilize frequency to less than 1 part per million (PPM).
2. The NTP subnet architecture must be hierarchical by stratum, where synchronization flows from primary servers at the lowest stratum successively to secondary servers at progressively higher strata. The primary servers must be reliably synchronized to national standards by radio, satellite, telephone modem, or calibrated atomic clock. All primary and secondary servers must deliver continuous time based on UTC, even when leap seconds are inserted in the UTC timescale. The servers must provide accurate and precise time, even with significant network jitter and oscillator wander.
3. The subnet must be reliable and survivable, even under unstable network conditions and where connectivity may be lost for periods up to days. This requires redundant time servers and diverse transmission paths, as well as a dynamically reconfigurable subnet architecture. Failing or misoperating servers must be recognized and reconfiguration performed automatically without operator direction or assistance.
4. The synchronization protocol must operate continuously and provide update information at rates sufficient to compensate for the expected wander of the room temperature quartz oscillators used in ordinary computer clocks. It must operate efficiently with large numbers of time servers and clients in continuous-polled and procedure-call modes and in broadcast and unicast configurations. The protocol must operate in existing Internets, including a spectrum of architectures ranging from personal workstations to supercomputers, but make minimal demands on the operating system and infrastructure services.
5. Security provisions must include cryptographic protection against accidental or willful intrusion, including message modification, replay, and clogging attacks. Means must be available to securely identify and authenticate servers and protect against masquerade, intended or accidental. Some implementations may include access controls that selectively allow or refuse requests from designated networks and limit the rate of requests serviced.
6. Means must be provided to record significant events in the system log and to record performance data for offline analysis. Some implementations may include the ability to monitor and control the servers and clients from a remote location using cryptographically secure procedures. Some implementations may include the ability to remotely enable and disable specific protocol features and to add, modify, and delete timing sources.
7. Server software, especially client software, must be easily built, installed, and configured using standard system tools. It must operate in most if not all computer architectures and operating systems in common use today. The software must be available free of charge and without limitations on use, distribution, or incorporation in products for sale.
Parting Shots
The latest NTPv4 software, called the reference implementation in this topic, is the product of almost three decades of development and refinement by a team of over four dozen volunteer contributors and countless deputized bug catchers in the field. The volunteer corps represents several countries, professions, and technical skill sets—the copyright page in the NTP documentation acknowledges all of them. While this topic is mostly about NTPv4, there still are a number of timekeepers running legacy versions, so this topic speaks to older versions as well. When necessary, differences between versions are identified in context.
NTP in one version or another has been running for almost three decades in the Internet. In fact, a claim can be made that it is the longest-running continuously operating application protocol in the Internet. NTP is widely deployed in hosts and routers in the Internet of today, although only a fraction have been surveyed [8]. The protocol and algorithms have continuously evolved from humble beginnings and have adapted over the years as the Internet itself grew up. Thus, it is important that new developments do not make older versions obsolete. The current protocol implementation is backward compatible with previous versions but includes several new features described in other topics.
NTP has spawned a commercial enterprise of its own. Several firms make NTP servers integrated with a GPS receiver or telephone modem. NTP is used by research projects, service providers, broadcasters, air traffic control, brokerage houses, and the intranets of many large corporations and universities. NTP time is disseminated using public servers operated by the national standards laboratories of the United States and many other countries of the world. In fact, not only does the Sun never set on NTP, but also it now never even gets close to the horizon. NTP subnets have been discovered on ships and airplanes all over the world, on the seafloor and space vehicles, and most recently in Antarctica. A deployment on the Moon and Mars is anticipated in the near future.
The current software and documentation release is available free of charge (but see the copyright notice) via the Web at http://www.ntp.org. The distribution has been ported to almost every computer architecture known from PCs to Crays (but only as a server on IBM mainframes) and embedded in products. The build-and-install process is largely automatic and requires no architecture or operating system configuration. Much more is said about this in the documentation included in the software distribution on the Web. Online resources at this Web site include many articles and reports cited in this topic, together with topical briefings, project descriptions, mail, and newsgroups. A Google for "network time protocol" at the time of this writing returned 21.8 million hits.
