Network Time Protocol (NTP)
RFC 958

Document Type RFC - Unknown (September 1985; No errata)
Obsoleted by RFC 1119, RFC 1059, RFC 1305
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 958 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
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]
Show full document text