NTP what is it?
NTP is widelyused to synchronise the time on computers on the internet. NTP providesthe ability to access time services, organise the time synchronisationsubnet and adjust the local clock in each participating subnet computer.Typically, NTP provides accuracies of between 1 and 50 milliseconds dependingon the time source and network paths.
Network TimeProtocol can be utilised to synchronise the time on computers across anetwork. A time server is utilised to obtain the correct time from a timesource and adjust the local time in each participating computer.
Toview Galleon Time Servers-click here
The timesource used by the time server is extremely important as this forms thebasis of all time updates across the network. Recent studies show an alarmingnumber 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 offsetsof over 10 seconds. Incredibly, one time source was offset by a staggering6 years. Only 28% of the internet based stratum 1 clocks actually appearsto be useful, based on research by Nelson Minar, MIT Media Lab Cambridge,MA USA .
Misconfigurationappears to be the main cause for inaccurate time sources provided by theinternet.
The integrityof the time source utilised by the time server cannot be stressed morehighly. The accuracy of each computer on the network is dependant on theaccuracy of the time source utilised by the time server. A useful ruleis 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 MediaLab Cambridge, MA USA
"This survey has captured the state of the NTP network in November1999. The network is growing rapidly and seems to be managing reasonablywell. Timing statistics suggest that delays and accuracies have improvedover the years, helping clock accuracy for everyone. This survey uncoverstwo problems: the number of bad clocks on the network, and the unbalancednature of the network load.
The number of bad clocks was a truly surprising result. Only 28% of thestratum 1 clocks found appear to actually be useful"
The conclusionby Nelson Minar underlines the importance of ensuring that for commercialapplications it is essential to use an accurate auditable time sourcesuch as a radio atomic clock, or GPS time
OperatingModes And Addressing
NTP Version4 can operate in either unicast (point to point), multicast (point tomultipoint) or anycast (multipoint to point) modes.
A unicastclient sends a request to a designated server at its unicast address andexpects a reply from which it can determine the time and, optionally,the roundtrip delay and local clock offset relative to the server.
A multicastserver periodically sends a unsolicited message to a designated IPv4 orIPv6 local broadcast address or multicast group address and ordinarilyexpects no requests from clients. A multicast client listens on this addressand ordinarily sends no requests.
An anycastclient sends a request to a designated IPv4 or IPv6 local broadcast addressor multicast group address. One or more anycast servers reply with theirindividual unicast addresses. The client binds to the first one received,then continues operation in unicast mode.
Multicastservers should respond to client unicast requests, as well as send unsolicitedmulticast messages. Multicast clients may send unicast requests in orderto determine the network propagation delay between the server and clientand then continue operation in multicast mode.
In unicastmode, the client and server end-system addresses are assigned followingthe usual IPv4, IPv6 or OSI conventions. In multicast mode, the serveruses 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 entireInternet. The scoping, routing and group membership procedures are determinedby considerations beyond the scope of this document. For IPv4, the IANAhas assigned the multicast group address 224.0.1.1 for NTP, which is usedboth by multicast servers and anycast clients. NTP multicast addressesfor IPv6 and OSI have yet to be determined.
Multicastclients listen on the designated local broadcast address or multicastgroup address. In the case of local broadcast addresses, no further provisionsare necessary. In the case of IP multicast addresses, the multicast clientand anycast server must implement the Internet Group Management Protocol(IGMP) [DEE89], in order that the local router joins the multicast groupand relays messages to the IPv4 or IPv6 multicast group addresses assignedby the IANA. Other than the IP addressing conventions and IGMP, thereis no difference in server or client operations with either the localbroadcast address or multicast group address.
It is importantto adjust the time-to-live (TTL) field in the IP header of multicast messagesto a reasonable value, in order to limit the network resources used bythis (and any other) multicast service. Only multicast clients in scopewill receive multicast server messages. Only co-operating anycast serversin scope will reply to a client request. The engineering principles whichdetermine the proper value to be used are beyond the scope of this document.
Anycast modeis designed for use with a set of co-operating servers whose addressesare not known beforehand by the client. An anycast client sends a requestto the designated local broadcast or multicast group address as describedbelow. For this purpose, the NTP multicast group address assigned by theIANA is used. One or more anycast servers listen on the designated localbroadcast address or multicast group address. Each anycast server, uponreceiving a request, sends a unicast reply message to the originatingclient. The client then binds to the first such message received and continuesoperation in unicast mode. Subsequent replies from other anycast serversare ignored.
In the caseof SNTP as specified herein, there is a very real vulnerability that SNTPmulticast clients can be disrupted by misbehaving or hostile SNTP or NTPmulticast servers elsewhere in the Internet, since at present all suchservers use the same IPv4 multicast group address assigned by the IANA.Where necessary, access control based on the server source address canbe used to select only the designated server known to and trusted by theclient. The use of cryptographic authentication scheme defined in RFC-1305is optional; however, implementers should be advised that extensions tothis scheme are planned specifically for NTP multicast and anycast modes.
While notintegral to the SNTP specification, it is intended that IP broadcast addresseswill be used primarily in IP subnets and LAN segments including a fullyfunctional NTP server with a number of dependent SNTP multicast clientson the same subnet, while IP multicast group addresses will be used onlyin 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 02139US A
|
