Synchronizing networked computers using Network Time Protocol

01 Nov. 1999

Department of Electrical & Communications Engineering
Helsinki University of Technology

The Network Time Protocol provides a mechanism to synchronize time on computers across an internet. NTP was first described in the RFC-958 and has evolved a lot after that. The version 2 of the NTP is described in RFC-1119. This essay is based on NTP version 3 that is described in RFC-1305. The NTP is evolved from the Time Protocol and the ICMP Time stamp message[3].

The NTP is built on the Internet Protocol (IP) and User Datagram Protocol (UDP). Also it is deigned in such a way that it can be easily adapted to other protocol suites. [3] Typically NTP is used over the Internet which is characterized by multiple paths, multiple gateways, highly varying delays and unreliable nets. The NTP is designed to maintain accuracy and robustness even when used in such adverse conditions. In the Internet scenario, NTP provides accuracy of 1-50 ms depending on the characteristics of the synchronization source, network paths and local clock hardware[1].

In its simplest form the NTP is modeled as a client/server system. This model is enough for use on local nets having a public time server and many clients.[3] The client sends an NTP message to one or more time servers and processes the replies received. The server interchanges the addresses and ports, overwrites certain fields in the message, recalculates checksums and returns the message immediately to the client. Based on the information returned by the server the client determines the server time with respect to the local time and adjusts its clock accordingly. Also the message contains information to calculate the time keeping accuracy and to select the best time sources from several time servers possible.

The full scale NTP system has a number of client and servers or peers arranged in a dynamically reconfigurable, hierarchically distributed configuration[3]. In such a model the time information is exchanged not only from different servers to the client but also between the peers. A database of the time, server and peer information is maintained in each node of the network. Sophisticated filtering and clock selection algorithms are run to select the best time information to synchronize to and discard the inferior ones. This kind of model provides an inherent fault tolerance to the NTP system as if a client looses a server it still has other servers to synchronize to. Even if the client looses all the servers it will synchronize to its peers.

 Fig 1 shows the NTP time server architecture[2]. Here the system is synchronized to multiple peers through the NTP associations. This provides the redundancy to the system. The clock filters select the best from a window of multiple clock offset samples. Intersection and clustering algorithms pick best subset of sensible clock offsets and discards the inferior ones. The combining algorithm computes the weighted average of offsets and the accuracy. The loop filter and local clock oscillator (LCO) implement the hybrid phase/frequency feedback loop to minimize jitter.[4]

The NTP can operate in either unicast (point to point) or broadcast (point to multipoint) modes. A unicast client sends a request to a server and expects a reply from which it can determine the time, round trip delay and local clock offset relative to the server. A broadcast server periodically sends a message to a designated IP broadcast address or IP multicast group address and normally does not expect any requests from the clients. A broadcast client listens to the IP broadcast address or IP multicast group address and does not send any requests to the servers. Some broadcast servers may elect to respond to client requests as well as send unsolicited broadcast messages, while some broadcast clients may elect to send requests only in order to determine the network propagation delay between the server and the client.[2]

The NTP synchronization subnet is a network of primary and secondary time servers, clients and interconnecting transmission paths. A primary time server is directly synchronized to a primary reference time source.[3] Usually primary time servers may be radio clock, atomic clock, etc. The secondary servers get synchronized to the primary servers possibly via other secondary servers over network transmission path possibly shared by other services. The primary and secondary servers form a hierarchical tree model with primary servers at the root and the secondary servers towards the leaves. The time accuracy decreases as it moves from the root to the leaves.

The accuracy of the servers in the NTP synchronization subnet is defined by a number called stratum. The topmost level primary servers in the hierarchy have stratum 1. The stratum 1 servers are directly connected to the primary time sources like radio clocks, atomic clock, etc. which has the stratum 0[5]. The stratum increases by one as one moves down the tree towards leaves with the servers in the same level in the tree having the same stratum number.

So a stratum 2 server obtain time from a stratum 1 server, a stratum 3 server obtain time from stratum 2 server, and so on. In order to avoid long lived synchronization loops the number of strata is limited to 15. The lower the stratum number the higher the time accuracy of the server. However excessive number of clients connected to one server will degrade the system. So it is generally best to restrict the number of clients connected to a server to below 100, unless the primary purpose of the client is to act as secondary server to provide time synchronization. Usually the majority of the end user systems will run at stratum 3, 4 or 5.

The Fig 2 shows typical NTP configurations. In the figure the numbers indicate the stratum of that particular node. Fig 2a shows workstations use multicast mode with department servers. Fig 2b shows department servers use client/server modes with multiple campus time servers and symmetric modes with each other. Fig 2c shows campus servers use client/server modes with up to six different external primary time servers and symmetric modes with each other and external secondary buddy servers.[4]

The robustness requirements of NTP similar to other multiple-peer distributed protocols. These include protection from faulty implementation, improper operation and replay attacks with or without data modification. These requirements are very important in the case of NTP because damage can propagate throughout the system.[3]

The NTP suggests an optional authentication mechanism and support for this mechanism is not required in order to confirm to the NTP specification. The NTP authentication mechanism operates at the application level and is designed to protect against unauthorized message stream modification and misrepresentation of source by insuring that unbroken, authenticated path exist between a trusted stratum 1 server in a particular synchronization subnet and all other servers in that subnet. It employs a crypto-checksum computed by the server 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. [3]

The NTP is designed to be used in networks with wide range of delays and jitter characteristics. It is typically employed on Internet synchronization subnet and use a suite of software package with a lot of options and algorithms and are relatively complex real-time applications. For many applications the sheer size and complexity of the NTP is not appropriate. The Simple Network Time Protocol (SNTP) is a simplified version of NTP and can be used in situations where less stringent timing accuracy will suffice.

By the nature the SNTP is less accurate than the NTP and so there are recommended restrictions on how it can be used. The SNTP clients should operate only at the leaves (highest stratum) of the subnet. It should be used in such a way that no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP servers should be used only at the root (stratum 1) of the sublet and it should not be synchronized to any other source than the radio clock.

Like NTP, SNTP can operate in either unicast or broadcast modes. The model for SNTP client operating with a NTP or SNTP server is a RPC client with no persistent state. In unicast mode, the client sends a request to the server and expects a reply from the server. In broadcast mode, the client sends no requests but waits for a broadcast message from one or more servers depending on the configuration. Unicast client and broadcast server messages are normally sent at periods from 64 s to 1024 s, depending on client and server configurations.[1]

The model of SNTP server operating with either a NTP or SNTP client is an RPC server with no persistent state. Snice SNTP is a cut down version od NTP and does not implement the full set of algorithms to support redundant peers and diverse network paths, it is recommended operate a SNTP server only in conjunction with a source of external synchronization like a reliable radio clock. In such a case the server always operates at stratum 1. The SNTP server can operate in unicast mode, broadcast mode or both at the same time. In unicast mode, the server receives a request message, modifies certain fields in the NTP or SNTP header and returns the message to the sender. The server may or may not respond if not synchronized to a correctly operating radio clock and it is upto the clients to handle such situations. In broadcast mode, the server sends messages only if synchronized to a correctly operating reference clock. It is desirable for a broadcast server to support unicast mode also. This is because a potential broadcast client can calculate the propagation delay using client/server messages prior to regular operation using only broadcast messages.[1]