1 / 42

Internet Time Services and NTP, The Network Time Protocol

Internet Time Services and NTP, The Network Time Protocol. Judah Levine Time and Frequency Division NIST Boulder jlevine@boulder.nist.gov 303 497-3903. Components of NTP. Message format and parameters Measurement protocol Typical Performance Traceability Private NTP

Download Presentation

Internet Time Services and NTP, The Network Time Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Internet Time Services and NTP, The Network Time Protocol Judah Levine Time and Frequency Division NIST Boulder jlevine@boulder.nist.gov 303 497-3903

  2. Components of NTP • Message format and parameters • Measurement protocol • Typical Performance • Traceability • Private NTP • Layered services and authentication • Reference clocks • Peer selection • Clock discipline algorithm • Hierarchy definition and realization • Remote Administration and Monitoring

  3. Message Format and Parameters • Format defined in RFC 1305 • Packets are udp/ip • checksum-based error detection • simple connectionless service • no guarantee of delivery • no detection of lost packets • Similar to mailing a letter to a recipient who does not expect it • Message authentication is optional • Authenticator added to message

  4. NTP Transport • Independent of physical layer in principle • Performance depends on physical layer in practice • All versions of NTP can use ipV4 protocol • Newer versions also support ipV6 • NIST has 1 ipV6 server (October, 2012)

  5. NTP Time Datum • Reference scale is UTC • Time parameters are 64 bits long: Seconds since 1900.0 (32 bits, unsigned) Fraction of a second (32 bits, unsigned) • Dynamic range: 136+ years • rollover in 2036 • Resolution: 2-32 s  232 ps • a time of 0.0 is usually treated as an error

  6. Some Other Parameters • Advance notice of leap second • leap second at end of today when set • Positive leap second in progress • Transmit 23:59:59 twice • Effectively stop the system clock • Slewing methods (Google) • Clock unsynchronized flag • don’t trust the time message • Health and leap second use same bits.

  7. More Parameters • Message authenticator (optional) • Stratum, precision and reference signal of the server (ref ip or local clock type) • Stratum indicates number of links to UTC, not quality of oscillator • Administrative data (alternate format) • not completely defined in the protocol specification. • Usually can be ignored without problems

  8. Authentication - 1 • Keys identified by index number into local file which has the key value. • <Key Number> M <key value> • Configuration • Trustedkey <Key Number> • MD5 hash of the NTP key+packet • XMT: Append result and key index • RCV: Detects additional packet data • Compute hash using key specified by number, compare with received value • No decryption of received message • MD5 algorithm has no known inverse • Distribution of keys is a headache

  9. Authentication - 2 • Authentication only identifies server • Guarantees integrity • Does not affect accuracy • Does not affect traceability • Possible “man in the middle” attacks • Delay valid message • Replay old message

  10. Two-Way Protocol d Client Server

  11. If we assume that Then If the truth is that Then

  12. Limits of asymmetry error k=1, =/2 Round-trip delay→  0 k=0, = -/2 Smaller delay has smaller asymmetry error

  13. Measurement Protocols • Two-way daemon with measured delay • uses udp/ip port 123 on server and client • Periodic queries to multiple servers • Client-server or peer to peer • Broadcast mode, no measured delay • Single server, multiple clients • Local LAN or Internet multi-cast • Single-shot client, e.g. ntpdate and sntp • port on server is udp/ip port 123 • any port on client is okay • measures delay using usual 2-way method

  14. Typical Performance - 1 • Typical asymmetry few percent of delay • Small LAN • 10 ms best case ever on 2-node LAN • 220 ms on real-world small LAN • Typical large-building LAN • 2 ms RMS typical • Internet with few hops • 10 – 20 ms • Long distance and/or slow or busy link • 100 ms – 1 s

  15. Typical Performance - 2 • Accuracy determined by accuracy of network delay measurement • not a function of message format • PTP/1588 not better on same network • Accuracy degraded on network with asymmetric traffic delays • Web server • David Mills “huff-n-puff” filter • Minimal delay implies minimal asymmetry

  16. Traceability • Log files at stratum-1 server • Positive entries important • NIST servers maintain internal log files of each calibration cycle • Log files at end user necessary and may be sufficient • Queries to multiple servers are useful • Log files shift the legal burden of proof • “best practices” argument • Commercial equipment very poor and inadequate

  17. Traceability and private NTP • Private NTP uses special hardware or software at both ends of link • “Trusted Master Clock” at NMI • “Trusted Reference Clock” at end user • Monitoring of user system using separate system • Issuing calibration certificates

  18. NIST Position • Time from a private NTP systems is not traceable to NIST even if hardware is at NIST • Traceability ends at the signal connector • NIST does not accept integrity or availability requirements • Some computer security issues not resolved

  19. Layered services - 1 • Document time stamping using Public/Private key pair • Hash code of document submitted to NIST • Document itself not transmitted or revealed • NIST adds NTP time stamp and signs combination with private key • Validity and time stamp can be verified using public key • NIST does not have to archive transaction

  20. Layered Services - 2 • Certified Mail • NIST receives e-mail message from sender • Message can be encrypted • NIST adds time stamp and signature • NIST forwards mail to recipient • Support for Kerberos ticket system • Time-based method to validate users and applications

  21. NIST position • Layered services will be realized by private companies only • NIST service ends at time-service portal • NTP stratum-1 server, ACTS, … • NIST provides authenticated stratum-1 time service to registered users • Registration linked to ip address of user • Unique key for each user

  22. References • RFC literature for NTP • 958, 1059, 1119, 1305, 1589, 1769, 2030, ... • Other NTP literature • IEEE/ACM Trans. Networking, Jun 1995, pp. 245-254. • IEEE Trans. Comm., Oct. 1991, pp. 1482-93 • www.ee.udel.edu/~mills/ntp.html • David Mills: mills@udel.edu

  23. Other Methods • Lockclock: • IEEE/ACM Trans. Networks, 2/95, pp. 42-50. • Interlock and Autolock: • IEEE Trans. UFFC, 7/99, pp. 888-896. • Other (non-NTP) methods • IEEE Trans. Parallel Distributed Sys., 3/94, pp. 474-487.

  24. Backup Slides • Reference Clock Models • Peer Selection Method • Clock Discipline: PLL vs FLL • Polling Interval Considerations • NTP Administration • NTP Message Format and Parameters

  25. Reference Clock Models (NTP) • Local reference clock (radio clock ...) incorporated as a peer with a pseudo-ip address (127.127.t.u). • pseudo-ip points to internal driver • Relationship to clock looks like client- server -- clock is polled periodically and time enters standard peer selection procedures.

  26. Reference Clock (JL) • Local reference clock is a special device with its own driver • Separate from NTP • statistics tuned to clock type • Better than standard NTP in normal operations • Worse in certain error situations • Longer polling interval

  27. NTP Peer Selection - 1 • Initial specification is in configuration file using ip address + keywords • server, peer, prefer • Typical configuration specifies multiple servers • All (or multiple) servers queried on every measurement cycle

  28. NTP Peer Selection - 2 • Method favors lowest stratum, lowest distance peer that claims to be healthy and does not appear to be an outlier with respect to the other systems. • Best case • multiple queries improves accuracy by 1/N • Cost increases as N • Statistics of local clock not used • Short-term stability better than network

  29. JL Peer management • Algorithm normally queries only one server • Compare received time difference with expected value • Statistics of local clock used in algorithm • Weighted sum of local clock time and time received from remote server • Weighting based on previous variance • Query additional server only if error detected

  30. NTP Clock Discipline - I • “Original recipe” NTP uses PLL • Local clock is steered primarily in frequency using filtered time difference. • goal of loop is to drive time error to 0 • approximate second-order loop. • Polling interval must be kept short so that variance is time noise • Discrimination implemented with queries to multiple servers • Cost ~ N, benefit ~ 1/N • loop converts time noise to frequency noise

  31. NTP Clock Discipline - II • New version of NTP uses mixed PLL/FLL • crossover as function of interval between measurements and message quality • FLL drives frequency error to 0 • time is correct on the average • defined by Adev • better decoupling of time/frequency

  32. JL Clock Discipline • Control loop is pure FLL • parameters set to Adev analysis • Time step detector similar to AT1 • Simplifies separation of time and frequency fluctuations • allows time steps with no associated change in frequency

  33. FLL vs. PLL Considerations • Server noise spectrum seen through channel vs. noise of local clock. • local clock often better at short times. • Frequency noise and phase noise are not necessarily correlated • FLL generally cheaper • makes better use of better hardware • FLL slower to remove time steps

  34. Cost/Performance tradeoff • A PLL must operate in domain where phase noise is dominant problem • Degradation at longer times is not easily determined • FLL usually operates in white FM domain • Cheaper to start with (longer averaging) • Quantitative tradeoff based on AVAR • Implemented in Autolock

  35. Polling Interval • Statistics of remote clock seen through the network should be better than local clock variance • Cost/benefit analysis: • White phase noise: • Cost ~ N, • Variance ~ 1/N

  36. Daemon Administration • NTP packet modes 6 and 7 • uses same udp/ip packets to same port • configure daemon parameters • monitor performance and usage • dangerous without authentication • NTP distribution provides utility tasks • ntpq • xntpdc

  37. Network Administration • Public servers identified in lists maintained by David Mills at the University of Delaware and ntp.org • RFC literature defines standards, etc. • newsgroup comp.protocols.time.ntp • “Free for all” typical of the Internet • Almost all people are good citizens almost all of the time

  38. NIST Server Administration • All network-based administration disabled for security reasons • Each server maintains internal state variable history • Each server linked to alarm system via dial-up modem. • Separate monitoring and alarm system runs on system in Boulder

  39. Definition of Stratum • Lower stratum clocks are closer to a primary time source • WWVB, GPS, ... • Properties or quality of local oscillator do not influence stratum definition • NTP message format supports stratum, accuracy estimate and synch. source

  40. More Parameters • Message authenticator (optional) • Stratum, precision and reference signal of the server (ref ip or local clock type) • Stratum indicates number of links to UTC, not quality of oscillator • Administrative data (alternate format) • not completely defined in the protocol specification. • Usually can be ignored without problems

  41. NTP Service model • Operate servers at many locations • Minimizes delay error for all users • No single point of failure • How are remote servers synchronized? • Time link to source of UTC(lab) • Performance limited by delay jitter and asymmetry • Static asymmetry generally cannot be detected

  42. Hierarchy Radio, GPS, cesium, ... 1 1 1 p p c-s p p 2 2 2

More Related