diff options
Diffstat (limited to 'doc/rfc/rfc958.txt')
| -rw-r--r-- | doc/rfc/rfc958.txt | 797 |
1 files changed, 797 insertions, 0 deletions
diff --git a/doc/rfc/rfc958.txt b/doc/rfc/rfc958.txt new file mode 100644 index 0000000..4b2324e --- /dev/null +++ b/doc/rfc/rfc958.txt @@ -0,0 +1,797 @@ + +Network Working Group D.L. Mills +Request for Comments: 958 M/A-COM Linkabit + September 1985 + + Network Time Protocol (NTP) + + +Status of this Memo + + This RFC suggests a proposed protocol for the ARPA-Internet + community, and requests discussion and suggestions for improvements. + Distribution of this memo is unlimited. + +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 + + This document describes the Network Time Protocol (NTP), a protocol + for synchronizing a set of network clocks using a set of distributed + clients and servers. NTP is built on the User Datagram Protocol + (UDP) [13], which provides a connectionless transport mechanism. It + is evolved from the Time Protocol [7] and the ICMP Timestamp message + [6] and is a suitable replacement for both. + + NTP provides the protocol mechanisms to synchronize time in principle + to precisions in the order of nanoseconds while preserving a + non-ambiguous date, at least for this century. The protocol includes + provisions to specify the precision and estimated error of the local + clock and the characteristics of the reference clock to which it may + be synchronized. However, the protocol itself specifies only the + data representation and message formats and does not specify the + synchronizing algorithms or filtering mechanisms. + + Other mechanisms have been specified in the Internet protocol suite + to record and transmit the time at which an event takes place, + including the Daytime protocol [8] and IP Timestamp option [9]. The + NTP is not meant to displace either of these mechanisms. Additional + information on network time synchronization can be found in the + + +Mills [Page 1] + + + +RFC 958 September +Network Time Protocol + + + References at the end of this document. An earlier synchronization + protocol is discussed in [3] and synchronization algorithms in [2], + [5], [10] and [12]. Experimental results on measured roundtrip delays + and clock offsets in the Internet are discussed in [4] and [11]. A + comprehensive mathematical treatment of clock synchronization can be + found in [1]. + +2. Service Model + + The intent of the service for which this protocol is designed is to + connect a few primary reference clocks, synchronized by wire or radio + to national standards, to centrally accessable resources such as + gateways. These gateways would use NTP between them to cross-check + the primary clocks and mitigate errors due to equipment or + propagation failures. Some number of local-net hosts, serving as + secondary reference clocks, would run NTP with one or more of these + gateways. In order to reduce the protocol overhead, these hosts + would redistribute time to the remaining local-net hosts. In the + interest of reliability selected hosts might be equipped with less + accurate but less expensive radio clocks and used for backup in case + of failure of the primary and/or secondary clocks or communication + paths between them. + + In the normal configuration a subnetwork of primary and secondary + clocks will assume a hierarchical organization with the more accurate + clocks near the top and the less accurate below. NTP provides + information that can be used to organize this hierarchy on the basis + of precision or estimated error and even to serve as a rudimentary + routing algorithm to organize the subnetwork itself. However, the + NTP protocol does not include a specification of the algorithms for + doing this, which is left as a topic for further study. + +3. Protocol Overview + + There is no provision for peer discovery, acquisition, or + authentication in NTP. Data integrity is provided by the IP and UDP + checksums. No reachability, circuit-management, duplicate-detection + or retransmission facilities are provided or necessary. The service + can operate in a symmetric mode, in which servers and clients are + indistinguishable yet maintain a small amount of state information, + or in an unsymmetric mode in which servers need maintain no client + state other than that contained in the client request. Moreover, + only a single NTP message format is necessary, which simplifies + implementation and can be used in a variety of solicited or + unsolicited polling mechanisms. + + In what may be the most common (unsymmetric) mode a client sends an + + +Mills [Page 2] + + + +RFC 958 September +Network Time Protocol + + + NTP message to one or more servers and processes the replies as + received. The server interchanges addresses and ports, fills in or + overwrites certain fields in the message, recalculates the checksum + and returns it immediately. Information included in the NTP message + allows each client/server peer to determine the timekeeping + characteristics of its other peers, including the expected accuracies + of their clocks. Using this information each peer is able to select + the best time from possibly several other clocks, update the local + clock and estimate its accuracy. + + It should be recognized that clock synchronization requires by its + nature long periods and multiple comparisons in order to maintain + accurate timekeeping. While only a few comparisons are usually + adequate to maintain local time to within a second, primarily to + protect against broken hardware or synchronization failure, periods + of hours or days and tens or hundreds of comparisons are required to + maintain local time to within a few tens of milliseconds. + Fortunately, the frequency of comparisons can be quite small and + almost always non-intrusive to normal network operations. + +4. State Variables and Formats + + NTP timestamps are represented as a 64-bit fixed-point number, in + seconds relative to 0000 UT on 1 January 1900. The integer part is + in the first 32 bits and the fraction part in the last 32 bits, as + shown in the following diagram. + + 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 allows convenient multiple-precision arithmetic and + conversion to Time Protocol representation (seconds), but does + complicate the conversion to ICMP Timestamp message representation + (milliseconds). The low-order fraction bit increments at about + 0.2-nanosecond intervals, so a free-running one-millisecond clock + will be in error only a small fraction of one part per million, or + less than a second per year. + + In some cases a particular timestamp may not be available, such as + when the protocol first starts up. In these cases the 64-bit field + is set to zero, indicating the value is invalid or undefined. + + + +Mills [Page 3] + + + +RFC 958 September +Network Time Protocol + + + Following is a description of the various data items used in the + protocol. Details of packet formats are presented in the Appendices. + + Leap Indicator + + This is a two-bit code warning of an impending leap-second to be + inserted in the internationally coordinated Standard Time + broadcasts. A leap-second is occasionally added or subtracted + from Standard Time, which is based on atomic clocks, to maintain + agreement with Earth rotation. When necessary, the corrections + are notified in advance and executed at the end of the last day of + the month in which notified, usually June or December. When a + correction is executed the first minute of the following day will + have either 59 or 61 seconds. + + Status + + This is a six-bit code indicating the status of the local clock. + Values are assigned to indicate whether it is 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 synchronized to Standard Time), secondary clocks + (remotely synchronized via various network protocols) and even + eyeball-and-wristwatch. + + 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 last set. The value is in seconds, + with fraction point between bits 15 and 16, and is computed by the + sender based on 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]. + + + +Mills [Page 4] + + + +RFC 958 September +Network Time Protocol + + + 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 fraction point to the left of the high-order + bit. While for most purposes this value can be estimated based on + the hardware characteristics, it is possible to compute it quite + accurately, as described in [12]. + + Reference Clock Identifier + + This is a 32-bit code identifying the particular reference clock. + The interpretation of its value depends on value of Reference + Clock Type. In the case of a primary clock locally synchronized + to Standard Time (type 1), the value is an ASCII string + identifying the clock. In the case of a secondary clock remotely + synchronized 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 established 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 synchronized, the value is zero. + + Originate Timestamp + + This is a 64-bit timestamp established by the client host and + 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 established by the server host and + 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 established by the server host and + 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. + + + +Mills [Page 5] + + + +RFC 958 September +Network Time Protocol + + +5. Protocol Operation + + The intent of this document is to specify a standard for data + representation and message format which can be used for a variety of + synchronizing algorithms and filtering mechanisms. Accordingly, the + information in this section should be considered a guide, rather than + a concise specification. Nevertheless, it is expected that a + standard Internet distributed timekeeping protocol with concisely + specified synchronizing and filtering algorithms can be evolved from + the information in this section. + + 5.1. Protocol Modes + + The distinction between client and server is significant only in + the way they interact in the request/response interchange. The + same NTP message format is used by each peer and contains the same + data relative to the other peer. In the unsymmetric mode the + client periodically sends an NTP message to the server, which then + responds within some interval. Usually, the server simply + interchanges addresses and ports, fills in the required + information and sends the message right back. Servers operating in + the unsymmetric mode then need retain no state information between + client requests. + + In the symmetric mode the client/server distinction disappears. + Each peer maintains a table with as many entries as active peers, + each entry including a code uniquely identifying the peer (e.g. + Internet address), together with status information 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 these timestamps. The + interval between sending NTP messages is managed solely by the + sending peer and is unaffected by the arrival of NTP messages from + other peers. + + The mode assumed by a peer can be determined by inspection of the + UDP Source Port and Destination Port fields (see Appendix A). If + both of these fields contain the NTP service-port number 123, the + peer is operating in symmetric mode. If they are different and + the Destination Port field contains 123, this is a client request + and the receiver is expected to reply in the manner described + above. If they are different and the Source Port field contains + 123, this is a server reply to a previously sent client request. + + + + + + +Mills [Page 6] + + + +RFC 958 September +Network Time Protocol + + + 5.2. Message Processing + + The significant events of interest in NTP occur usually near the + times the NTP messages depart and arrive the client/server. In + order to maintain the highest accuracy it is important that the + timestamps associated with these events be computed as close as + possible to the hardware or software driver associated with the + communications link and, in particular, that departure timestamps + be recomputed for each retransmission, if used at the link level. + + An NTP message is constructed as follows (see Appendix B). The + source peer constructs the UDP header and the LI, Status, + Reference Clock Type and Precision fields in the NTP data portion. + Next, it determines the current synchronizing source and + constructs the Type and Reference Clock Identifier fields. From + its timekeeping algorithm (see [12] for examples) it determines + the Reference Timestamp, Estimated Error and Estimated Drift Rate + fields. Then it copies into the Receive Timestamp and Transmit + Timestamp fields the data saved from the latest message received + from the destination peer and, finally, computes the Originate + Timestamp field. + + The destination peer calculates the roundtrip delay and clock + offset relative to the source peer as follows. Let t1, t2 and t3 + represent the contents of the Originate Timestamp, Receive + Timestamp and Transmit Timestamp fields and t4 the local time the + NTP message is received. Then the roundtrip delay d and clock + offset c is: + + d = (t4 - t1) - (t3 - t2) and c = (t2 - t1 + t3 - t4)/2 . + + The implicit assumption in the above 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 + + The client/server peers have an opportunity to learn a good deal + about each other in the NTP message exchange. For instance, each + can learn about the characteristics of the other clocks and select + among them the most accurate to use as reference clock, compute + the estimated error and drift rate and use this information to + manage the dynamics of the subnetwork of clocks. An outline of a + suggested mechanism is as follows: + + Included in the table of timestamps for each peer are state + + +Mills [Page 7] + + + +RFC 958 September +Network Time Protocol + + + variables to indicate the precision, as well as the current + estimated delay, offset, error and drift rate of its local clock. + These variables are updated for each NTP message received from the + peer, after which the estimated error is periodically recomputed + on the basis of elapsed time and estimated drift rate. + + Assuming symmetric mode, a polling interval is established for + each peer, depending upon its normal synchronization source, + precision and intrinsic accuracy, which might be determined in + advance or even as the result of observation. The delay and + clock-offset samples obtained can be filtered using + maximum-likelihood techniques and algorithms described in [12]. + + From time to time a local-clock correction is computed from the + offset data accumulated as above, perhaps using algorithms + described in [10] and [12]. The correction causes the local clock + to run slightly fast or slow to the corrected time or to jump + instantaneously to the correct time, depending on the magnitude of + the correction. 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 that manual intervention is not normally + required. + + As a byproduct of the above operations an estimate of local-clock + error and drift rate can be computed. Note that 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. It does not take a leap of imagination to see that + the estimated error, delay or precision, or some combination of + them, can be used as a metric for a simple min-hop-type routing + algorithm to organize the subnetwork so as to provide the most + accurate time to all peers and to provide automatic fallback to + alternate sources in case of failures. + + A variety of network configurations can be included in the above + scenario. In the case of networks supporting 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 typical networks of this type have a very low + propagation delay, the roundtrip-delay calculation can be omitted + and the clients need not broadcast in return. Thus, the + requirement to save per-peer timestamps is removed, so that the + Receive Timestamp and Transmit Timestamp fields can be set to zero + and the local-clock offset becomes simply the difference between + the Originate Timestamp and the local time upon arrival. In the + case of long-delay satellite networks with broadcast capabilities, + + +Mills [Page 8] + + + +RFC 958 September +Network Time Protocol + + + an accurate measure of roundtrip delay is usually available from + the channel-scheduling algorithm, so the per-peer timestamps again + can be avoided. + + 5.4. Leap Seconds + + A standard mechanism to effect leap-second correction is not a + part of this specification. It is expected that the Leap + Indicator bits would be set by hand in the primary reference + clocks, then trickle down to all other clocks in the network, + which would execute the correction at the specified time and reset + the bits. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mills [Page 9] + + + +RFC 958 September +Network Time Protocol + + +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. + + + +Mills [Page 10] + + + +RFC 958 September +Network Time Protocol + + +Appendix A. UDP Header Format + + An NTP packet consists of the UDP header followed by the NTP data + portion. The format of the UDP header and the interpretation of its + fields are described in [13] and are not part of the NTP + specification. They are shown below for completeness. + + 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 the case of unsymmetric mode and a + client request this field is assigned by the client host, while + for a server reply it is copied from the Destination Port field of + the client request. In the case of symmetric mode, both the + Source Port and Destination Port fields are assigned the NTP + service-port number 123. + + Destination Port + + UDP destination port number. In the case of unsymmetric mode and a + client request this field is assigned the NTP service-port number + 123, while for a server reply it is copied form the Source Port + field of the client request. In the case of symmetric mode, both + the Source Port and Destination Port fields are assigned the NTP + service-port number 123. + + Length + + Length of the request or reply, including UDP header, in octets. + + Checksum + + Standard UDP checksum. + + + + + + + + + +Mills [Page 11] + + + +RFC 958 September +Network Time Protocol + + +Appendix B. NTP Data Format + + The format of the NTP data portion, which immediately follows the UDP + header, is shown below along with a description of its fields. + + 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) + + Code warning of impending leap-second to be inserted at the end of + the last day of the current month. Bits are coded as follows: + + 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 + + Code indicating status of local clock. Values are defined as + follows: + + +Mills [Page 12] + + + +RFC 958 September +Network Time Protocol + + + 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) + + Code identifying the type of reference clock. Values are defined + as follows: + + 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 + + Signed integer in the range +32 to -32 indicating the precision of + the local clock, in seconds to the nearest power of two. + + Estimated Error + + Fixed-point number indicating the estimated error of the local + clock at the time last set, in seconds with fraction point between + bits 15 and 16. + + Estimated Drift Rate + + Signed fixed-point number indicating the estimated drift rate of + the local clock, in dimensionless units with fraction point to the + left of the high-order bit. + + Reference Clock + Identifier + + Code identifying the particular reference clock. In the case of + type 1 (primary reference), this is a left-justified, zero-filled + ASCII string identifying the clock, for example: + + WWVB WWVB radio clock (60 KHz) + + + + +Mills [Page 13] + + + +RFC 958 September +Network Time Protocol + + + GOES GOES satellite clock (468 HMz) + WWV WWV radio clock (2.5/5/10/15/20 MHz) + (and others as necessary) + + In the case of type 2 (secondary reference) this is 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 + + Local time at which the local clock was last set or corrected. + + Originate Timestamp + + Local time at which the request departed the client host for the + service host. + + Receive Timestamp + + Local time at which the request arrived at the service host. + + Transmit Timestamp + + Local time at which the reply departed the service host for the + client host. + + + + + + + + + + + + + + + + + + + + + + + + +Mills [Page 14] + |