RFC 958

Network Time Protocol (NTP) 🕰️✨

• RFC: 958 📄
• Title: Network Time Protocol (NTP)
• Author: D.L. Mills, M/A-COM Linkabit 🧑‍💻
• Working Group: Network Working Group
• Date: September 1985 🗓️
• Status: a proposed protocol for the ARPA-Internet community, put out there to get discussion and suggestions for improvements 💬
• Obsoletes / Updates: this header doesn't list any RFCs it obsoletes or updates 🤷‍♀️

part 1 of 3 💖 this is the first chunk, more is coming!

Status of this Memo 📜

okay so this memo is a proposed protocol for the ARPA-Internet community 🛰️. It's asking people to talk about it and send in ideas for making it better. Distribution of this memo is unlimited, so share it with everyone 🌸.

Table of Contents 🗂️

1.      Introduction
2.      Service Model
3.      Protocol Overview
4.      State Variables and Formats
5.      Protocol Operation
5.1.    Protocol Modes
5.2.    Message Processing
5.3.    Network Considerations
5.4.    Leap Seconds
6.      References
Appendix A. UDP Header Format
Appendix B. NTP Data Format

1. Introduction ✨

bestie, this doc is all about the Network Time Protocol (NTP) 🕰️, which is a way to get a bunch of network clocks synced up using a crew of distributed clients and servers. NTP is built on top of the User Datagram Protocol (UDP) [13], which gives you a connectionless transport. It evolved from the Time Protocol [7] and the ICMP Timestamp message [6], and it's a suitable replacement for both. Iconic glow-up 💅

NTP gives you the protocol mechanisms to sync time to precisions in the order of nanoseconds while keeping the date unambiguous, at least for this century 😭🫶. It also has provisions to specify the precision and estimated error of your local clock, plus the characteristics of the reference clock you might sync to. BUT here's the tea 🍵: the protocol itself only specifies the data representation and message formats. It does not specify the synchronizing algorithms or filtering mechanisms. That part is up to you, babe 💅.

Other mechanisms in the Internet protocol suite can also record and send out the time an event happens, like the Daytime protocol [8] and the IP Timestamp option [9]. NTP is not trying to displace either of them 🙅‍♀️. You can find more info on network time sync in the References at the end of this document. An earlier sync protocol is discussed in [3], and sync algorithms are covered in [2], [5], [10] and [12]. Experimental results on measured roundtrip delays and clock offsets in the Internet are discussed in [4] and [11]. And if you want a comprehensive mathematical treatment of clock sync, go to [1] 🧮.

2. Service Model 🤝

The whole point of this service is to connect a few primary reference clocks, which get synced by wire or radio to national standards, to centrally accessible resources like gateways 🌐. The gateways use NTP between themselves to cross-check the primary clocks and smooth out errors caused by equipment or propagation failures. Some local-net hosts act as secondary reference clocks and run NTP with one or more of these gateways. To cut down on protocol overhead, those hosts redistribute time to the remaining local-net hosts. For reliability, selected hosts might be equipped with less accurate but less expensive radio clocks. They're there as backup in case the primary and/or secondary clocks, or the communication paths between them, fail 🛟.

In the normal setup, a subnetwork of primary and secondary clocks forms a hierarchy, with the more accurate clocks near the top and the less accurate ones below 🪜. NTP provides info you can use to organize this hierarchy based on precision or estimated error, and it can even work as a rudimentary routing algorithm to organize the subnetwork itself. Lowkey cool 😎. But the NTP protocol does not include a specification of the algorithms for doing this. That's left as a topic for further study 🔬.

3. Protocol Overview 🛰️

There's no provision for peer discovery, acquisition, or authentication in NTP 🙈. Data integrity comes from the IP and UDP checksums. No reachability, circuit-management, duplicate-detection or retransmission facilities are provided or necessary, so it's giving minimalism 🌿.

The service can run in a symmetric mode, where servers and clients are indistinguishable yet still keep a small amount of state info. It can also run in an unsymmetric mode, where servers don't need to keep any client state beyond what's in the client's request. Also, only a single NTP message format is necessary. That keeps implementation simple, and it works with a variety of solicited or unsolicited polling mechanisms 🧚.

In what may be the most common mode (unsymmetric), a client sends an NTP message to one or more servers and processes the replies as they come in 📨. The server swaps the addresses and ports, fills in or overwrites certain fields in the message, recalculates the checksum, and sends it back right away. The info in the NTP message lets each client/server peer figure out the timekeeping characteristics of its other peers, including the expected accuracies of their clocks 👀. With that, each peer can pick the best time out of possibly several other clocks, update its local clock, and estimate its own accuracy. Main character energy 👑.

Clock sync is a long game 🐢. It takes long periods and multiple comparisons to keep accurate timekeeping. A few comparisons are usually enough to keep local time within a second, mainly to protect against broken hardware or sync failure. But you need periods of hours or days and tens or hundreds of comparisons to keep local time within a few tens of milliseconds. The good news is that the frequency of comparisons can be pretty small, and it's almost always non-intrusive to normal network operations 🫶.

4. State Variables and Formats 🧮

NTP timestamps are represented as a 64-bit fixed-point number, counting seconds relative to 0000 UT on 1 January 1900 🎀. The integer part is in the first 32 bits and the fraction part is in the last 32 bits, as shown in the diagram below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Integer Part                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Fraction Part                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This format makes multiple-precision arithmetic super convenient and lets you convert to Time Protocol representation (seconds) easily. It does complicate the conversion to ICMP Timestamp message representation (milliseconds), though 😤. The low-order fraction bit increments at about 0.2-nanosecond intervals, so a free-running one-millisecond clock will only be off by a small fraction of one part per million, or less than a second per year ⏱️.

Sometimes a particular timestamp isn't available, like right when the protocol first starts up. In those cases the 64-bit field is set to zero, which means the value is invalid or undefined 🫥.

Here's a rundown of the various data items used in the protocol. The packet format details are in the Appendices 📚.

Leap Indicator 🌗

This is a two-bit code that warns about an impending leap second to be inserted in the internationally coordinated Standard Time broadcasts. Leap seconds are occasionally added to or subtracted from Standard Time, which is based on atomic clocks, to keep things in agreement with Earth's rotation 🌍. When one is needed, the corrections get announced in advance and executed at the end of the last day of the month in which they were announced, usually June or December 📅. When a correction is executed, the first minute of the following day will have either 59 or 61 seconds. Wild 🙃.

Status 🚦

This is a six-bit code showing the status of the local clock. Values are assigned to indicate whether it's operating correctly or in one of several error states ⚠️.

Reference Clock Type 🏷️

This is an eight-bit code identifying the type of reference clock used to set the local clock. Values are assigned for primary clocks (locally synced to Standard Time), secondary clocks (remotely synced via various network protocols), and even eyeball-and-wristwatch 👀⌚. Iykyk 💀.

Precision 🎯

This is a 16-bit signed integer indicating the precision of the local clock, in seconds to the nearest power of two. For instance, a 60-Hz line-frequency clock would be assigned the value -6, while a 1000-Hz crystal clock would be assigned the value -10 💎.

Estimated Error 📉

This is a 32-bit fixed-point number indicating the estimated error of the local clock at the time it was last set. The value is in seconds, with the fraction point between bits 15 and 16. The sender computes it from the reported error of the reference clock, the precision and drift rate of the local clock, and the time the local clock was last set 🧠. For statistical purposes, this quantity can be assumed equal to the estimated or computed standard deviation, as described in [12] 📊.

Estimated Drift Rate 🌊

This is a 32-bit signed fixed-point number indicating the estimated drift rate of the local clock. The value is dimensionless, with the fraction point to the left of the high-order bit. For most purposes this can be estimated from the hardware characteristics, but it's possible to compute it quite accurately, as described in [12] 🎯.

Reference Clock Identifier 🪪

This is a 32-bit code identifying the particular reference clock. How you interpret its value depends on the value of Reference Clock Type. For a primary clock that's locally synced to Standard Time (type 1), the value is an ASCII string identifying the clock 🔤. For a secondary clock that's remotely synced to an Internet host via NTP (type 2), the value is the 32-bit Internet address of that host 🌐. In other cases, the value is undefined 🫥.

Reference Timestamp ⏰

This is a 64-bit timestamp set by the server or client host as the timestamp (presumably obtained from a reference clock) most recently used to update the local clock. If the local clock has never been synced, the value is zero 0️⃣.

Originate Timestamp 🚀

This is a 64-bit timestamp set by the client host, specifying the local time at which the request departed for the service host. It will always have a nonzero value 💜.

Receive Timestamp 📬

This is a 64-bit timestamp set by the server host, specifying the local time at which the request arrived from the client host. If no request has ever arrived from the client, the value is zero 🫠.

Transmit Timestamp 📤

This is a 64-bit timestamp set by the server host, specifying the local time at which the reply departed for the client host. If no request has ever arrived from the client, the value is zero 🫠.

5. Protocol Operation 🌸

Okay so the whole point of this doc is to set a standard for how data is represented and how messages are formatted, so that it can work with a bunch of different synchronizing algorithms and filtering mechanisms 💅 That means this section is more of a guide than a tight spec, but it's expected that a proper internet timekeeping protocol with tightly specified sync and filtering algorithms can grow out of everything here 🌈

5.1. Protocol Modes 🦋

Client vs server only matters for how the two of them interact in the request/response exchange ✨ Every peer uses the same NTP message format, and it holds the same data relative to the other peer. In the unsymmetric mode, the client periodically sends an NTP message to the server, and the server responds within some interval. Usually the server just swaps the addresses and ports, fills in the required info, and sends the message right back 💖 Servers in the unsymmetric mode don't need to keep any state info between client requests, which is so clean 🧚

In the symmetric mode, the client/server split disappears completely 🫶 Each peer keeps a table with one entry per active peer. Each entry has a code that uniquely identifies the peer (for example, its Internet address), plus status info and a copy of the Originate Timestamp and Receive Timestamp values last received from that peer. The peer periodically sends an NTP message to each of these peers, including the latest copy of those timestamps. The gap between sending NTP messages is managed only by the sending peer, and it isn't affected by NTP messages arriving from other peers 🎀

The mode a peer is using can be figured out by checking the UDP Source Port and Destination Port fields (see Appendix A) 🔍 If both fields contain the NTP service-port number 123, the peer is in symmetric mode. If they're different and the Destination Port field contains 123, it's a client request, and the receiver is expected to reply the way described above. If they're different and the Source Port field contains 123, it's a server reply to a client request that was sent earlier 😭

5.2. Message Processing 💅

The important NTP events happen pretty much right when the messages leave and arrive between client and server ⏱️ To keep the highest accuracy, the timestamps for these events should be computed as close as possible to the hardware or software driver tied to the communications link. Especially, departure timestamps should be recomputed for every retransmission, if retransmission is used at the link level 🔥

Here's how an NTP message gets built (see Appendix B) 🧩 The source peer builds the UDP header plus the LI, Status, Reference Clock Type and Precision fields in the NTP data portion. Next, it figures out the current synchronizing source and builds the Type and Reference Clock Identifier fields. From its timekeeping algorithm (see [12] for examples), it works out the Reference Timestamp, Estimated Error and Estimated Drift Rate fields. Then it copies the data saved from the latest message received from the destination peer into the Receive Timestamp and Transmit Timestamp fields and, last of all, computes the Originate Timestamp field ✨

The destination peer works out the roundtrip delay and clock offset relative to the source peer like this 🧮 Let t1, t2 and t3 be the contents of the Originate Timestamp, Receive Timestamp and Transmit Timestamp fields, and let t4 be the local time the NTP message is received. Then the roundtrip delay d and clock offset c are:

d = (t4 - t1) - (t3 - t2)  and  c = (t2 - t1 + t3 - t4)/2 .

The big assumption here is that the one-way delay is statistically half the roundtrip delay, and that the intrinsic drift rates of both the client and server clocks are small and close to the same value 🤞

5.3. Network Considerations 🌐

Client and server peers get to learn a lot about each other during the NTP message exchange 👀 For example, each one can learn about the characteristics of the other's clocks and pick the most accurate one to use as the reference clock. They can also compute the estimated error and drift rate and use that info to manage the dynamics of the subnetwork of clocks. Here's an outline of a suggested mechanism 📝

Each peer's table of timestamps includes state variables for the precision, plus the current estimated delay, offset, error and drift rate of its local clock 💜 These get updated for each NTP message received from that peer. After that, the estimated error is periodically recomputed based on elapsed time and the estimated drift rate ⏳

Assuming symmetric mode, a polling interval is set up for each peer. It depends on that peer's normal synchronization source, its precision and its intrinsic accuracy. That interval might be determined in advance or even come from observation 📊 The delay and clock-offset samples can be filtered using maximum-likelihood techniques and the algorithms described in [12] 🧠

From time to time, a local-clock correction is computed from the offset data collected above, maybe using algorithms described in [10] and [12] 🛠️ The correction makes the local clock run slightly fast or slow until it reaches the corrected time, or it makes the clock jump instantly to the correct time, depending on how big the correction is. See [5] and [11] for a discussion of local-clock implementation models and synchronizing algorithms 📚 Note that the expectation here is that all network clocks are maintained by these algorithms, so manual intervention is normally not required 🙌

As a byproduct of all this, an estimate of local-clock error and drift rate can be computed ✨ Also, the magnitude of the error estimate must always be greater than that of the selected reference clock by at least the inherent precision of the local clock. Honestly it's not a huge leap to see that the estimated error, delay or precision, or some mix of them, can be used as a metric for a simple min-hop-type routing algorithm 🦋 That lets you organize the subnetwork so all peers get the most accurate time, and it gives automatic fallback to alternate sources if something fails 🛟

A bunch of network configurations fit into this scenario 🌈 In networks that support a broadcast function, for example, NTP messages can be broadcast from one or more server hosts and picked up by client hosts sharing the same cable 📡 Since networks like this have a very low propagation delay, the roundtrip-delay calculation can be left out, and the clients don't need to broadcast back. So the requirement to save per-peer timestamps goes away. The Receive Timestamp and Transmit Timestamp fields can be set to zero, and the local-clock offset becomes just the difference between the Originate Timestamp and the local time when the message arrives 🎀 For long-delay satellite networks with broadcast capabilities, an accurate measure of roundtrip delay is usually available from the channel-scheduling algorithm, so per-peer timestamps can be avoided there too 🛰️

5.4. Leap Seconds 🕛

A standard mechanism for leap-second correction is not part of this specification 🙈 It's expected that the Leap Indicator bits get set by hand in the primary reference clocks. Then they trickle down to all the other clocks in the network, which execute the correction at the specified time and reset the bits 💫

6. References 📚

1. Lindsay, W.C., and A.V. Kantak. Network Synchronization of Random Signals. IEEE Trans. Comm. COM-28, 8 (August 1980), 1260-1266.
2. Mills, D.L. Time Synchronization in DCNET Hosts. DARPA Internet Project Report IEN-173, COMSAT Laboratories, February 1981.
3. Mills, D.L. DCNET Internet Clock Service. DARPA Network Working Group Report RFC-778, COMSAT Laboratories, April 1981.
4. Mills, D.L. Internet Delay Experiments. DARPA Network Working Group Report RFC-889, M/A-COM Linkabit, December 1983.
5. Mills, D.L. DCN Local-Network Protocols. DARPA Network Working Group Report RFC-891, M/A-COM Linkabit, December 1983.
6. Postel, J. Internet Control Message Protocol. DARPA Network Working Group Report RFC-792, USC Information Sciences Institute, September 1981.
7. Postel, J. Time Protocol. DARPA Network Working Group Report RFC-868, USC Information Sciences Institute, May 1983.
8. Postel, J. Daytime Protocol. DARPA Network Working Group Report RFC-867, USC Information Sciences Institute, May 1983.
9. Su, Z. A Specification of the Internet Protocol (IP) Timestamp Option. DARPA Network Working Group Report RFC-781. SRI International, May 1981.
10. Marzullo, K., and S. Owicki. Maintaining the Time in a Distributed System. ACM Operating Systems Review 19, 3 (July 1985), 44-54.
11. Mills, D.L. Experiments in Network Clock Synchronization. DARPA Network Working Group Report RFC-957, M/A-COM Linkabit, August 1985.
12. Mills, D.L. Algorithms for Synchronizing Network Clocks. DARPA Network Working Group Report RFC-956, M/A-COM Linkabit, September 1985.
13. Postel, J. User Datagram Protocol. DARPA Network Working Group Report RFC-768, USC Information Sciences Institute, August 1980.

Appendix A. UDP Header Format ✨

Okay so an NTP packet is the UDP header followed by the NTP data portion 🎀. The UDP header and what its fields mean are described in [13]. They are not part of the NTP spec 🙈, but they're shown here for completeness because bestie deserves the full picture 💅.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Length             |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Source Port

UDP source port number 🦋. In unsymmetric mode, the client's request gets this field assigned by the client host, while the server's reply copies it from the Destination Port field of the client request. In symmetric mode, both the Source Port and Destination Port fields get the NTP service-port number 123. Two fields, same number, very twinning 👯‍♀️.

Destination Port

UDP destination port number 🌸. In unsymmetric mode, the client's request gets the NTP service-port number 123 here, while the server's reply copies it from the Source Port field of the client request. In symmetric mode, both the Source Port and Destination Port fields get the NTP service-port number 123, same as above, iconic 💜.

Length

Length of the request or reply, including UDP header, in octets 📏.

Checksum

Standard UDP checksum 🧚.

---

Appendix B. NTP Data Format ✨

Now the main event 👑. The NTP data portion sits right after the UDP header, and here's what it looks like, field by field, no cap 💀.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI |   Status  |      Type     |           Precision           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Estimated Error                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Estimated Drift Rate                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Reference Clock Identifier                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Reference Timestamp (64 bits)                 |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 Originate Timestamp (64 bits)                 |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                  Receive Timestamp (64 bits)                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                  Transmit Timestamp (64 bits)                 |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Leap Indicator (LI)

This is the warning code for an impending leap second, which gets inserted at the end of the last day of the current month ⏳. The bits are coded like this:

00      no warning
01      +1 second (following minute has 61 seconds)
10      -1 second (following minute has 59 seconds)
11      reserved for future use

Status

This code tells you the status of the local clock 🕰️. The values are:

0       clock operating correctly
1       carrier loss
2       synch loss
3       format error
4       interface (Type 1) or link (Type 2) failure
(additional codes reserved for future use)

Reference Clock Type (Type)

This code identifies what kind of reference clock you're dealing with 🔍. The values are:

0       unspecified
1       primary reference (e.g. radio clock)
2       secondary reference using an Internet host via NTP
3       secondary reference using some other host or protocol
4       eyeball-and-wristwatch
(additional codes reserved for future use)

Precision

A signed integer from +32 to -32 that describes the precision of the local clock, in seconds to the nearest power of two 🎯.

Estimated Error

A fixed-point number giving the estimated error of the local clock at the time it was last set, in seconds, with the fraction point between bits 15 and 16 🧮.

Estimated Drift Rate

A signed fixed-point number giving the estimated drift rate of the local clock, in dimensionless units, with the fraction point to the left of the high-order bit 📉.

Reference Clock Identifier

This code identifies the particular reference clock 🛰️, and what goes in it depends on the type:

• For type 1 (primary reference), it's a left-justified, zero-filled ASCII string that identifies the clock. For example:

WWVB    WWVB radio clock (60 KHz)
GOES    GOES satellite clock (468 HMz)
WWV     WWV radio clock (2.5/5/10/15/20 MHz)
(and others as necessary)

• For type 2 (secondary reference), it's the 32-bit Internet address of the reference host 🌐.
• In other cases, this field is reserved for future use and should be set to zero 🤫.

Reference Timestamp

The local time at which the local clock was last set or corrected ⏰.

Originate Timestamp

The local time at which the request departed the client host for the service host 📤.

Receive Timestamp

The local time at which the request arrived at the service host 📥.

Transmit Timestamp

The local time at which the reply departed the service host for the client host 💌.