NTP and NTP Clients
NTP time servers and NTP clients using network time protocol to the exact time distribution.

Atomic clock

Overview

NTP is widely used to synchronise the time on computers on the internet. NTP provides the ability to access time services, organise the time synchronisation subnet and adjust the local clock in each participating subnet computer. Typically, NTP provides accuracies of between 1 and 50 milliseconds depending on the time source and network paths.

Network Time Protocol can be utilised to synchronise the time on computers across a network. A time server is utilised to obtain the correct time from a time source and adjust the local time in each participating computer.

To view Galleon Time Servers - click here

The time source used by the time server is extremely important as this forms the basis of all time updates across the network. Recent studies show an alarming number of stratum 1 time sources on the internet are bad time keepers. A reported 391 of 957 supposedly stratum 1 NTP time sources had time offsets of over 10 seconds. Incredibly, one time source was offset by a staggering 6 years. Only 28% of the internet based stratum 1 clocks actually appears to be useful, based on research by Nelson Minar, MIT Media Lab Cambridge, MA USA .

Misconfiguration appears to be the main cause for inaccurate time sources provided by the internet.

The integrity of the time source utilised by the time server cannot be stressed more highly. The accuracy of each computer on the network is dependant on the accuracy of the time source utilised by the time server. A useful rule is to beware when obtaining the time from sources that cannot be validated, i.e. from an unknown third party across the internet.

Extracts from the Conclusion of the article by Nelson Minar, MIT Media Lab Cambridge, MA USA
"This survey has captured the state of the NTP network in November 1999. The network is growing rapidly and seems to be managing reasonably well. Timing statistics suggest that delays and accuracies have improved over the years, helping clock accuracy for everyone. This survey uncovers two problems: the number of bad clocks on the network, and the unbalanced nature of the network load.
The number of bad clocks was a truly surprising result. Only 28% of the stratum 1 clocks found appear to actually be useful"

The conclusion by Nelson Minar underlines the importance of ensuring that for commercial applications it is essential to use an accurate auditable time source such as a radio atomic clock, or GPS time

Operating Modes And Addressing

NTP Version 4 can operate in either unicast (point to point), multicast (point to multipoint) or anycast (multipoint to point) modes.

A unicast client sends a request to a designated server at its unicast address and expects a reply from which it can determine the time and, optionally, the roundtrip delay and local clock offset relative to the server.

A multicast server periodically sends a unsolicited message to a designated IPv4 or IPv6 local broadcast address or multicast group address and ordinarily expects no requests from clients. A multicast client listens on this address and ordinarily sends no requests.

An anycast client sends a request to a designated IPv4 or IPv6 local broadcast address or multicast group address. One or more anycast servers reply with their individual unicast addresses. The client binds to the first one received, then continues operation in unicast mode.

Multicast servers should respond to client unicast requests, as well as send unsolicited multicast messages. Multicast clients may send unicast requests in order to determine the network propagation delay between the server and client and then continue operation in multicast mode.

In unicast mode, the client and server end-system addresses are assigned following the usual IPv4, IPv6 or OSI conventions. In multicast mode, the server uses a designated local broadcast address or multicast group address. An IP local broadcast address has scope limited to a single IP subnet, since routers do not propagate IP broadcast datagrams. On the other hand, an IP multicast group address has scope extending to potentially the entire Internet. The scoping, routing and group membership procedures are determined by considerations beyond the scope of this document. For IPv4, the IANA has assigned the multicast group address 224.0.1.1 for NTP, which is used both by multicast servers and anycast clients. NTP multicast addresses for IPv6 and OSI have yet to be determined.

Multicast clients listen on the designated local broadcast address or multicast group address. In the case of local broadcast addresses, no further provisions are necessary. In the case of IP multicast addresses, the multicast client and anycast server must implement the Internet Group Management Protocol (IGMP) [DEE89], in order that the local router joins the multicast group and relays messages to the IPv4 or IPv6 multicast group addresses assigned by the IANA. Other than the IP addressing conventions and IGMP, there is no difference in server or client operations with either the local broadcast address or multicast group address.

It is important to adjust the time-to-live (TTL) field in the IP header of multicast messages to a reasonable value, in order to limit the network resources used by this (and any other) multicast service. Only multicast clients in scope will receive multicast server messages. Only co-operating anycast servers in scope will reply to a client request. The engineering principles which determine the proper value to be used are beyond the scope of this document.

Anycast mode is designed for use with a set of co-operating servers whose addresses are not known beforehand by the client. An anycast client sends a request to the designated local broadcast or multicast group address as described below. For this purpose, the NTP multicast group address assigned by the IANA is used. One or more anycast servers listen on the designated local broadcast address or multicast group address. Each anycast server, upon receiving a request, sends a unicast reply message to the originating client. The client then binds to the first such message received and continues operation in unicast mode. Subsequent replies from other anycast servers are ignored.

In the case of SNTP as specified herein, there is a very real vulnerability that SNTP multicast clients can be disrupted by misbehaving or hostile SNTP or NTP multicast servers elsewhere in the Internet, since at present all such servers use the same IPv4 multicast group address assigned by the IANA. Where necessary, access control based on the server source address can be used to select only the designated server known to and trusted by the client. The use of cryptographic authentication scheme defined in RFC-1305 is optional; however, implementers should be advised that extensions to this scheme are planned specifically for NTP multicast and anycast modes.

While not integral to the SNTP specification, it is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a fully functional NTP server with a number of dependent SNTP multicast clients on the same subnet, while IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain.

Acknowledgements

David L. Mills. Electrical Engineering Department, University of Delaware, Newark, DE 19716 USA
Nelson Minar. MIT Media Lab E15-305 20 Ames Street Cambridge, MA 02139 USA