Teknik Telekomunikasi    
   
Daftar Isi ☛
(Sebelumnya) Network switchNetwork-neutral data center (Berikutnya)

Network Time Protocol

Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

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 use. NTP was originally designed by David L. Mills of the University of Delaware, who still develops and maintains it with a team of volunteers.

Contents

Overview

NTP provides Coordinated Universal Time (UTC) including scheduled leap second adjustments. No information about time zones or daylight saving time is transmitted; this information is outside its scope and must be obtained separately.

NTP uses Marzullo's algorithm and is designed to resist the effects of variable latency. NTP can usually maintain time to within tens of milliseconds over the public Internet,[1] and can achieve 1 millisecond accuracy in local area networks under ideal conditions.[2]

As of June 2010[update], the current reference implementation is version 4 (NTPv4), which is a proposed standard as documented in RFC 5905. It succeeds version 3, specified in RFC 1305.

The protocol uses the User Datagram Protocol (UDP) on port number 123.[3]

SNTP

A less complex implementation of NTP, using the same protocol[4] but without requiring the storage of state over extended periods of time, is known as the Simple Network Time Protocol (SNTP). It is used in some embedded devices and in applications where high accuracy timing is not required (RFC 1361, RFC 1769, RFC 2030, RFC 4330 and RFC 5905).

NTP software implementations

Unix

For modern Unix systems, the NTP client is implemented as a daemon process that runs continuously in user space (ntpd). Because of sensitivity to timing, however, it is important to have the standard NTP clock phase-locked loop implemented in kernel space. All recent versions of Linux, BSD, Mac OS X, Solaris and AIX are implemented in this manner.

The NTP packet is a UDP datagram, carried on port 123.[5]

Microsoft Windows

Microsoft Windows NT 4.0 did not come with an NTP implementation. The reference implementation of NTP can be used on NT4 systems.[6]

All Microsoft Windows versions since Windows 2000 and Windows XP include the Windows Time Service ("w32time"),[7] which has the ability to sync the computer clock to an NTP server. The version in Windows 2000 and Windows XP only implements Simple NTP, and violates several aspects of the NTP version 3 standard.[8] Beginning with Windows Server 2003 and Windows Vista, a compliant implementation of full NTP is included.[9]

However, Microsoft does not guarantee that their implementation will be more accurate than 2 seconds.[10] If higher accuracy is desired, Microsoft recommends to use a different NTP implementation.[11]

Clock strata

Yellow arrows indicate a direct connection; red arrows indicate a network connection.
The U.S. Naval Observatory Alternate Master Clock at Schriever AFB (Colorado) is a Stratum 0 source for NTP

NTP uses a hierarchical, semi-layered system of levels of clock sources. Each level of this hierarchy is termed a stratum and is assigned a layer number starting with 0 (zero) at the top. The stratum level defines its distance from the reference clock and exists to prevent cyclical dependencies in the hierarchy. It is important to note that the stratum is not an indication of quality or reliability, it is common to find stratum 3 time sources that are higher quality than other stratum 2 time sources. This definition of stratum is also different from the notion of clock strata used in telecommunication systems.

Stratum 0
These are devices such as atomic (cesium, rubidium) clocks, GPS clocks or other radio clocks. Stratum-0 devices are traditionally not attached to the network; instead they are locally connected to computers (e.g., via an RS-232 connection using a pulse per second signal).
Stratum 1
These are computers attached to Stratum 0 devices. Normally they act as servers for timing requests from Stratum 2 servers via NTP. These computers are also referred to as time servers.
Stratum 2
These are computers that send NTP requests to Stratum 1 servers. Normally a Stratum 2 computer will reference a number of Stratum 1 servers and use the NTP algorithm to gather the best data sample, dropping any Stratum 1 servers that seem obviously wrong. Stratum 2 computers will peer with other Stratum 2 computers to provide more stable and robust time for all devices in the peer group. Stratum 2 computers normally act as servers for Stratum 3 NTP requests.
Stratum 3
These computers employ exactly the same algorithms for peering and data sampling as Stratum 2, and can themselves act as servers for stratum 4 computers, and so on.

While NTP (depending on what version of NTP protocol in use) supports up to 256 strata, only the first 16 are employed and any device at Stratum 16 is considered to be unsynchronized.

NTP timestamps

The 64-bit timestamps used by NTP consist of a 32-bit part for seconds and a 32-bit part for fractional second, giving NTP a time scale that rolls over every 232 seconds (136 years) and a theoretical resolution of 2−32 seconds (233 picoseconds). NTP uses an epoch of January 1, 1900. The first rollover occurs in 2036, prior to the UNIX year 2038 problem.

Implementations should disambiguate NTP time using a knowledge of the approximate time from other sources. Since NTP only works with the differences between timestamps and never their absolute values, the wraparound is invisible as long as the timestamps are within 68 years of each other. This means that the rollover will be invisible for most running systems, since they will have the correct time to within a very small tolerance. However, systems that are starting up need to know the date within no more than 68 years. Given the large allowed error, it is not expected that this is too onerous a requirement. One suggested method is to set the clock to no earlier than the system build date. Many systems use a battery powered hardware clock to avoid this problem.

Even so, future versions of NTP may extend the time representation to 128 bits: 64 bits for the second and 64 bits for the fractional-second. The current NTP4 format has support for Era Number and Era Offset, that when used properly should aid fixing date rollover issues. According to Mills, "The 64 bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64 bit second value is enough to provide unambiguous time representation until the universe goes dim."[12][note 1]

Clock synchronization algorithm

To synchronize its clock with a remote server, the NTP client must compute the round-trip delay time and the offset. The round-trip delay is computed as \delta = (t_3 - t_0 ) - ( t_2- t_1 ), where t_0 is the time of the request packet transmission, t_1 is the time of the request packet reception, t_2 is the time of the response packet transmission and t_3 is the time of the response packet reception. t_3 - t_0 is the time elapsed on the client side between the emission of the request packet and the reception of the response packet, while t_2- t_1 is the time the server waited before sending the answer. The offset is given by \theta = {(t_1 - t_0) + (t_2 - t_3 ) \over 2}.[13]

The NTP synchronization is correct when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, the synchronization has a systematic bias of half the difference between the forward and backward travel times.[14]

Leap seconds

NTP delivers UTC time. UTC is subject to scheduled leap seconds to synchronize the timescale to the rotation of the earth. When a leap second is added, NTP is suspended for 1 second. Because NTP has no mechanism for remembering the history of leap seconds, leap seconds cause the entire NTP timescale to shift by 1 second.[15][16]

Security concerns

Only a few security problems have been identified in the reference implementation of the NTP codebase in its 25+ year history.[17][18] The protocol has been undergoing revision and review over its entire history. As of January 2011, there are no security revisions in the NTP specification and no reports at CERT.[19] The current codebase for the reference implementation has been undergoing security audits from several sources for several years now, and there are no known high-risk vulnerabilities in the current released software.[20]

See also

Portal iconTime portal
  • Allan variance
  • Clock synchronization
  • International Atomic Time
  • ntpd, OpenNTPD and Ntpdate
  • NTP pool, a collection of worldwide computers that provide a highly accurate time via the Network Time Protocol
  • NTP server misuse and abuse
  • Synchronization
  • Time server
  • NITZ (Network Identity and Time Zone) a mechanism for provisioning local time and date, as well as network provider identity information to mobile devices via a wireless network
Other time synchronization protocols
  • DAYTIME protocol, older time synchronization protocol using TCP or UDP port 13
  • ICMP Timestamp and ICMP Timestamp Reply, older time synchronization protocol using ICMP
  • Precision Time Protocol, a high-precision protocol for use on local area networks
  • Time Protocol, older time synchronization protocol using TCP or UDP port 37

Notes

  1. ^ 2−64 seconds is about 54 zeptoseconds (light would travel 16.26 picometres, or approximately 0.31 �- Bohr radius), and 264 seconds is about 585 billion years.

References

  1. ^ "Executive Summary: Computer Network Time Synchronization". http://www.eecis.udel.edu/~mills/exec .html. Retrieved 2011-11-21.
  2. ^ "NTP FAQ". The NTP Project. http://www.ntp.org/ntpfaq/NTP-s-algo. htm#Q-ACCURATE-CLOCK. Retrieved 2011-08-27.
  3. ^ "Port Numbers". The Internet Assigned Numbers Authority (IANA). http://www.iana.org/assignments/port- numbers.
  4. ^ "Network Time Protocol Version 4: Protocol and Algorithms Specification". June 2010. p. 54. https://tools.ietf.org/html/rfc5905#s ection-14. Retrieved 2012-08-26. "Primary servers and clients complying with a subset of NTP, called the Simple Network Time Protocol (SNTPv4) [...], do not need to implement the mitigation algorithms [...] The fully developed NTPv4 implementation is intended for [...] servers with multiple upstream servers and multiple downstream servers [...] Other than these considerations, NTP and SNTP servers and clients are completely interoperable and can be intermixed [...]"
  5. ^ Page 16
  6. ^ "NTP 4.x for Windows NT". NTP Documentation Archive. http://doc.ntp.org/4.2.6/hints/winnt. html. Retrieved 2011-01-12.
  7. ^ "Windows Time Service Technical Reference". technet.microsoft.com. 2011-08-17. http://technet.microsoft.com/en-us/li brary/cc773061%28WS.10%29.aspx. Retrieved 2011-09-19.
  8. ^ "Windows Time Service page at NTP.org". Support.ntp.org. 2008-02-25. http://support.ntp.org/bin/view/Suppo rt/WindowsTimeService. Retrieved 2011-01-12.[dead link]
  9. ^ "How the Windows Time Service Works". technet.microsoft.com. 2010-03-12. http://technet.microsoft.com/en-us/li brary/cc773013%28WS.10%29.aspx. Retrieved 2011-09-19.
  10. ^ "Support boundary to configure the Windows Time service for high accuracy environments". Microsoft Corporation. 2011-10-19. http://support.microsoft.com/kb/93932 2. "The W32Time service is not a full-featured NTP solution [...] The W32Time service is primarily designed to [...] Make the Kerberos version 5 authentication protocol work. [And p]rovide loose sync time for client computers. [...] The W32Time service cannot reliably maintain sync time to the range of 1 to 2 seconds."
  11. ^ Ned Pyle (2007-10-23). "High Accuracy W32time Requirements". Microsoft Corporation. https://blogs.technet.com/b/askds/arc hive/2007/10/23/high-accuracy-w32time -requirements.aspx. Retrieved 2012-08-26. "In some cases, customers want the time accurate down to the second. [...] the purpose of this blog is to explain [...] why we recommend using other solutions"
  12. ^ University of Delaware Digital Systems Seminar presentation by David Mills, 2006-04-26
  13. ^ Mills, David L. (2005), NTP Clock Discipline Modelling and Analysis, p. 10, http://www.eecis.udel.edu/~mills/data base/brief/algor/algor.pdf, retrieved 2011-07-13
  14. ^ Gotoh, T; Imamura, K; Kaneko, A (2002). "Improvement of NTP time offset under the asymmetric network with double packets method". Conference on Precision Electromagnetic Measurements. pp. 448–449. doi:10.1109/CPEM.2002.1034915. http://ieeexplore.ieee.org/stamp/stam p.jsp?tp=&arnumber=1034915&us erType=inst
  15. ^ David Mills. "The NTP Timescale and Leap Seconds". http://www.eecis.udel.edu/~mills/leap .html. Retrieved 2011-09-15.
  16. ^ David Mills. "NTP Timescale and Leap Seconds". http://doc.ntp.org/4.1.2/leap.htm. Retrieved 2011-09-15.
  17. ^ "Security Notice". Support.ntp.org. 2009-12-10. http://support.ntp.org/security. Retrieved 2011-01-12.[dead link]
  18. ^ results returned by a search on "Network Time Protocol" at http://cert.org]
  19. ^ in RFC 778, RFC 891, RFC 956, RFC 958, RFC 1305, RFC 5905, and the NTPv4 specification, and no results returned by a search on "Network Time Protocol" at http://cert.org]
  20. ^ "Code Audit". Support.ntp.org. 2009-06-13. http://support.ntp.org/Main/CodeAudit. Retrieved 2011-01-12.[dead link]

Relevant RFCs

CodeNoteTitle
RFC 958(Obsoleted by: 1059, 1119, 1305)Network Time Protocol (NTP)
RFC 1059(Obsoleted by: 1119, 1305)Network Time Protocol (Version 1) Specification and Implementation
RFC 1119(Obsoleted by: 1305)Network Time Protocol (Version 2) Specification and Implementation
RFC 1305(Obsoleted by: 5905)Network Time Protocol (Version 3) Specification, Implementation and Analysis
RFC 1361(Obsoleted by: 1769)Simple Network Time Protocol (SNTP)
RFC 1769(Obsoleted by: 2030, 4330)Simple Network Time Protocol (SNTP)
RFC 2030(Obsoleted by: 4330)Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC 4330(Obsoleted by: 5905)Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
RFC 5905(Current as of 2012)Network Time Protocol Version 4: Protocol and Algorithms Specification

Further reading

  • Mills, David L.. Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis / CRC Press. ISBN 0-8493-5805-1.

External links

(Sebelumnya) Network switchNetwork-neutral data center (Berikutnya)