Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5905

Network Time Protocol Version 4: Protocol and Algorithms Specification

Pages: 110
Proposed Standard
Errata
Obsoletes:  13054330
Updated by:  782285739109
Part 1 of 5 – Pages 1 to 16
None   None   Next

Top   ToC   RFC5905 - Page 1
Internet Engineering Task Force (IETF)                          D. Mills
Request for Comments: 5905                                   U. Delaware
Obsoletes: 1305, 4330                                     J. Martin, Ed.
Category: Standards Track                                            ISC
ISSN: 2070-1721                                               J. Burbank
                                                                W. Kasch
                                                                 JHU/APL
                                                               June 2010


 Network Time Protocol Version 4: Protocol and Algorithms Specification

Abstract

The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5905.
Top   ToC   RFC5905 - Page 2
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

1. Introduction ....................................................4 1.1. Requirements Notation ......................................5 2. Modes of Operation ..............................................6 3. Protocol Modes ..................................................6 3.1. Dynamic Server Discovery ...................................7 4. Definitions .....................................................8 5. Implementation Model ...........................................10 6. Data Types .....................................................12 7. Data Structures ................................................16 7.1. Structure Conventions .....................................16 7.2. Global Parameters .........................................16 7.3. Packet Header Variables ...................................17 7.4. The Kiss-o'-Death Packet ..................................24 7.5. NTP Extension Field Format ................................25 8. On-Wire Protocol ...............................................26 9. Peer Process ...................................................30 9.1. Peer Process Variables ....................................31 9.2. Peer Process Operations ...................................33 10. Clock Filter Algorithm ........................................37
Top   ToC   RFC5905 - Page 3
   11. System Process ................................................39
      11.1. System Process Variables .................................40
      11.2. System Process Operations ................................41
           11.2.1. Selection Algorithm ...............................43
           11.2.2. Cluster Algorithm .................................44
           11.2.3. Combine Algorithm .................................45
      11.3. Clock Discipline Algorithm ...............................47
   12. Clock-Adjust Process ..........................................51
   13. Poll Process ..................................................51
      13.1. Poll Process Variables ...................................51
      13.2. Poll Process Operations ..................................52
   14. Simple Network Time Protocol (SNTP) ...........................54
   15. Security Considerations .......................................55
   16. IANA Considerations ...........................................58
   17. Acknowledgements ..............................................59
   18. References ....................................................59
      18.1. Normative References .....................................59
      18.2. Informative References ...................................59
   Appendix A.  Code Skeleton  .......................................61
     A.1.  Global Definitions  .......................................61
       A.1.1. Definitions, Constants, Parameters .....................61
       A.1.2. Packet Data Structures .................................65
       A.1.3. Association Data Structures ............................66
       A.1.4. System Data Structures .................................68
       A.1.5. Local Clock Data Structures ............................69
       A.1.6. Function Prototypes ....................................69
     A.2. Main Program and Utility Routines ..........................70
     A.3. Kernel Input/Output Interface ..............................73
     A.4. Kernel System Clock Interface ..............................74
     A.5. Peer Process ...............................................76
       A.5.1. receive() ..............................................77
       A.5.2. clock_filter() .........................................85
       A.5.3. fast_xmit() ............................................88
       A.5.4. access() ...............................................89
       A.5.5. System Process .........................................90
       A.5.6. Clock Adjust Process ..................................103
       A.5.7. Poll Process ..........................................104
Top   ToC   RFC5905 - Page 4

1. Introduction

This document defines the Network Time Protocol version 4 (NTPv4), which is widely used to synchronize system clocks among a set of distributed time servers and clients. It describes the core architecture, protocol, state machines, data structures, and algorithms. NTPv4 introduces new functionality to NTPv3, as described in [RFC1305], and functionality expanded from Simple NTP version 4 (SNTPv4) as described in [RFC4330] (SNTPv4 is a subset of NTPv4). This document obsoletes [RFC1305] and [RFC4330]. While certain minor changes have been made in some protocol header fields, these do not affect the interoperability between NTPv4 and previous versions of NTP and SNTP. The NTP subnet model includes a number of widely accessible primary time servers synchronized by wire or radio to national standards. The purpose of the NTP protocol is to convey timekeeping information from these primary servers to secondary time servers and clients via both private networks and the public Internet. Precisely tuned algorithms mitigate errors that may result from network disruptions, server failures, and possible hostile actions. Servers and clients are configured such that values flow towards clients from the primary servers at the root via branching secondary servers. The NTPv4 design overcomes significant shortcomings in the NTPv3 design, corrects certain bugs, and incorporates new features. In particular, expanded NTP timestamp definitions encourage the use of the floating double data type throughout the implementation. As a result, the time resolution is better than one nanosecond, and frequency resolution is less than one nanosecond per second. Additional improvements include a new clock discipline algorithm that is more responsive to system clock hardware frequency fluctuations. Typical primary servers using modern machines are precise within a few tens of microseconds. Typical secondary servers and clients on fast LANs are within a few hundred microseconds with poll intervals up to 1024 seconds, which was the maximum with NTPv3. With NTPv4, servers and clients are precise within a few tens of milliseconds with poll intervals up to 36 hours. The main body of this document describes the core protocol and data structures necessary to interoperate between conforming implementations. Appendix A contains a full-featured example in the form of a skeleton program, including data structures and code segments for the core algorithms as well as the mitigation algorithms used to enhance reliability and accuracy. While the skeleton program and other descriptions in this document apply to a particular implementation, they are not intended as the only way the required functions can be implemented. The contents of Appendix A are non-
Top   ToC   RFC5905 - Page 5
   normative examples designed to illustrate the protocol's operation
   and are not a requirement for a conforming implementation.  While the
   NTPv3 symmetric key authentication scheme described in this document
   has been carried over from NTPv3, the Autokey public key
   authentication scheme new to NTPv4 is described in [RFC5906].

   The NTP protocol includes modes of operation described in Section 2
   using data types described in Section 6 and data structures described
   in Section 7.  The implementation model described in Section 5 is
   based on a threaded, multi-process architecture, although other
   architectures could be used as well.  The on-wire protocol described
   in Section 8 is based on a returnable-time design that depends only
   on measured clock offsets, but does not require reliable message
   delivery.  Reliable message delivery such as TCP [RFC0793] can
   actually make the delivered NTP packet less reliable since retries
   would increase the delay value and other errors.  The synchronization
   subnet is a self-organizing, hierarchical, master-slave network with
   synchronization paths determined by a shortest-path spanning tree and
   defined metric.  While multiple masters (primary servers) may exist,
   there is no requirement for an election protocol.

   This document includes material from [ref9], which contains flow
   charts and equations unsuited for RFC format.  There is much
   additional information in [ref7], including an extensive technical
   analysis and performance assessment of the protocol and algorithms in
   this document.  The reference implementation is available at
   www.ntp.org.

   The remainder of this document contains numerous variables and
   mathematical expressions.  Some variables take the form of Greek
   characters, which are spelled out by their full case-sensitive name.
   For example, DELTA refers to the uppercase Greek character, while
   delta refers to the lowercase character.  Furthermore, subscripts are
   denoted with '_'; for example, theta_i refers to the lowercase Greek
   character theta with subscript i, or phonetically theta sub i.  In
   this document, all time values are in seconds (s), and all
   frequencies will be specified as fractional frequency offsets (FFOs)
   (pure number).  It is often convenient to express these FFOs in parts
   per million (ppm).

1.1. Requirements Notation

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
Top   ToC   RFC5905 - Page 6

2. Modes of Operation

An NTP implementation operates as a primary server, secondary server, or client. A primary server is synchronized to a reference clock directly traceable to UTC (e.g., GPS, Galileo, etc.). A client synchronizes to one or more upstream servers, but does not provide synchronization to dependent clients. A secondary server has one or more upstream servers and one or more downstream servers or clients. All servers and clients who are fully NTPv4-compliant MUST implement the entire suite of algorithms described in this document. In order to maintain stability in large NTP subnets, secondary servers SHOULD be fully NTPv4-compliant. Alternative algorithms MAY be used, but their output MUST be identical to the algorithms described in this specification.

3. Protocol Modes

There are three NTP protocol variants: symmetric, client/server, and broadcast. Each is associated with an association mode (a description of the relationship between two NTP speakers) as shown in Figure 1. In addition, persistent associations are mobilized upon startup and are never demobilized. Ephemeral associations are mobilized upon the arrival of a packet and are demobilized upon error or timeout. +-------------------+-------------------+------------------+ | Association Mode | Assoc. Mode Value | Packet Mode Value| +-------------------+-------------------+------------------+ | Symmetric Active | 1 | 1 or 2 | | Symmetric Passive | 2 | 1 | | Client | 3 | 4 | | Server | 4 | 3 | | Broadcast Server | 5 | 5 | | Broadcast Client | 6 | N/A | +-------------------+-------------------+------------------+ Figure 1: Association and Packet Modes In the client/server variant, a persistent client sends packet mode 4 packets to a server, which returns packet mode 3 packets. Servers provide synchronization to one or more clients, but do not accept synchronization from them. A server can also be a reference clock driver that obtains time directly from a standard source such as a GPS receiver or telephone modem service. In this variant, clients pull synchronization from servers.
Top   ToC   RFC5905 - Page 7
   In the symmetric variant, a peer operates as both a server and client
   using either a symmetric active or symmetric passive association.  A
   persistent symmetric active association sends symmetric active (mode
   1) packets to a symmetric active peer association.  Alternatively, an
   ephemeral symmetric passive association can be mobilized upon the
   arrival of a symmetric active packet with no matching association.
   That association sends symmetric passive (mode 2) packets and
   persists until error or timeout.  Peers both push and pull
   synchronization to and from each other.  For the purposes of this
   document, a peer operates like a client, so references to client
   imply peer as well.

   In the broadcast variant, a persistent broadcast server association
   sends periodic broadcast server (mode 5) packets that can be received
   by multiple clients.  Upon reception of a broadcast server packet
   without a matching association, an ephemeral broadcast client (mode
   6) association is mobilized and persists until error or timeout.  It
   is useful to provide an initial volley where the client operating in
   client mode exchanges several packets with the server, so as to
   calibrate the propagation delay and to run the Autokey security
   protocol, after which the client reverts to broadcast client mode.  A
   broadcast server pushes synchronization to clients and other servers.

   Loosely following the conventions established by the telephone
   industry, the level of each server in the hierarchy is defined by a
   stratum number.  Primary servers are assigned stratum one; secondary
   servers at each lower level are assigned stratum numbers one greater
   than the preceding level.  As the stratum number increases, its
   accuracy degrades depending on the particular network path and system
   clock stability.  Mean errors, measured by synchronization distances,
   increase approximately in proportion to stratum numbers and measured
   round-trip delay.

   As a standard practice, timing network topology should be organized
   to avoid timing loops and minimize the synchronization distance.  In
   NTP, the subnet topology is determined using a variant of the
   Bellman-Ford distributed routing algorithm, which computes the
   shortest-path spanning tree rooted on the primary servers.  As a
   result of this design, the algorithm automatically reorganizes the
   subnet, so as to produce the most accurate and reliable time, even
   when there are failures in the timing network.

3.1. Dynamic Server Discovery

There are two special associations, manycast client and manycast server, which provide a dynamic server discovery function. There are two types of manycast client associations: persistent and ephemeral. The persistent manycast client sends client (mode 3) packets to a
Top   ToC   RFC5905 - Page 8
   designated IPv4 or IPv6 broadcast or multicast group address.
   Designated manycast servers within range of the time-to-live (TTL)
   field in the packet header listen for packets with that address.  If
   a server is suitable for synchronization, it returns an ordinary
   server (mode 4) packet using the client's unicast address.  Upon
   receiving this packet, the client mobilizes an ephemeral client (mode
   3) association.  The ephemeral client association persists until
   error or timeout.

   A manycast client continues sending packets to search for a minimum
   number of associations.  It starts with a TTL equal to one and
   continuously adding one to it until the minimum number of
   associations is made or when the TTL reaches a maximum value.  If the
   TTL reaches its maximum value and yet not enough associations are
   mobilized, the client stops transmission for a time-out period to
   clear all associations, and then repeats the search cycle.  If a
   minimum number of associations has been mobilized, then the client
   starts transmitting one packet per time-out period to maintain the
   associations.  Field constraints limit the minimum value to 1 and the
   maximum to 255.  These limits may be tuned for individual application
   needs.

   The ephemeral associations compete among themselves.  As new
   ephemeral associations are mobilized, the client runs the mitigation
   algorithms described in Sections 10 and 11.2 for the best candidates
   out of the population, the remaining ephemeral associations are timed
   out and demobilized.  In this way, the population includes only the
   best candidates that have most recently responded with an NTP packet
   to discipline the system clock.

4. Definitions

A number of technical terms are defined in this section. A timescale is a frame of reference where time is expressed as the value of a monotonically increasing binary counter with an indefinite number of bits. It counts in seconds and fractions of a second, when a decimal point is employed. The Coordinated Universal Time (UTC) timescale is defined by ITU-R TF.460 [ITU-R_TF.460]. Under the auspices of the Metre Convention of 1865, in 1975 the CGPM [CGPM] strongly endorsed the use of UTC as the basis for civil time. The Coordinated Universal Time (UTC) timescale represents mean solar time as disseminated by national standards laboratories. The system time is represented by the system clock maintained by the hardware and operating system. The goal of the NTP algorithms is to minimize both the time difference and frequency difference between UTC and the system clock. When these differences have been reduced below nominal tolerances, the system clock is said to be synchronized to UTC.
Top   ToC   RFC5905 - Page 9
   The date of an event is the UTC time at which the event takes place.
   Dates are ephemeral values designated with uppercase T.  Running time
   is another timescale that is coincident to the synchronization
   function of the NTP program.

   A timestamp T(t) represents either the UTC date or time offset from
   UTC at running time t.  Which meaning is intended should be clear
   from the context.  Let T(t) be the time offset, R(t) the frequency
   offset, and D(t) the aging rate (first derivative of R(t) with
   respect to t).  Then, if T(t_0) is the UTC time offset determined at
   t = t_0, the UTC time offset at time t is

   T(t) = T(t_0) + R(t_0)(t-t_0) + 1/2 * D(t_0)(t-t_0)^2 + e,

   where e is a stochastic error term discussed later in this document.
   While the D(t) term is important when characterizing precision
   oscillators, it is ordinarily neglected for computer oscillators.  In
   this document, all time values are in seconds (s) and all frequency
   values are in seconds-per-second (s/s).  It is sometimes convenient
   to express frequency offsets in parts-per-million (ppm), where 1 ppm
   is equal to 10^(-6) s/s.

   It is important in computer timekeeping applications to assess the
   performance of the timekeeping function.  The NTP performance model
   includes four statistics that are updated each time a client makes a
   measurement with a server.  The offset (theta) represents the
   maximum-likelihood time offset of the server clock relative to the
   system clock.  The delay (delta) represents the round-trip delay
   between the client and server.  The dispersion (epsilon) represents
   the maximum error inherent in the measurement.  It increases at a
   rate equal to the maximum disciplined system clock frequency
   tolerance (PHI), typically 15 ppm.  The jitter (psi) is defined as
   the root-mean-square (RMS) average of the most recent offset
   differences, and it represents the nominal error in estimating the
   offset.

   While the theta, delta, epsilon, and psi statistics represent
   measurements of the system clock relative to each server clock
   separately, the NTP protocol includes mechanisms to combine the
   statistics of several servers to more accurately discipline and
   calibrate the system clock.  The system offset (THETA) represents the
   maximum-likelihood offset estimate for the server population.  The
   system jitter (PSI) represents the nominal error in estimating the
   system offset.  The delta and epsilon statistics are accumulated at
   each stratum level from the reference clock to produce the root delay
   (DELTA) and root dispersion (EPSILON) statistics.  The
   synchronization distance (LAMBDA) equal to EPSILON + DELTA / 2
   represents the maximum error due to all causes.  The detailed
Top   ToC   RFC5905 - Page 10
   formulations of these statistics are given in Section 11.2.  They are
   available to the dependent applications in order to assess the
   performance of the synchronization function.

5. Implementation Model

Figure 2 shows the architecture of a typical, multi-threaded implementation. It includes two processes dedicated to each server, a peer process to receive messages from the server or reference clock, and a poll process to transmit messages to the server or reference clock. ..................................................................... . Remote . Peer/Poll . System . Clock . . Servers . Processes . Process .Discipline. . . . . Process . .+--------+. +-----------+. +------------+ . . .| |->| |. | | . . .|Server 1| |Peer/Poll 1|->| | . . .| |<-| |. | | . . .+--------+. +-----------+. | | . . . . ^ . | | . . . . | . | | . . .+--------+. +-----------+. | | +-----------+. . .| |->| |. | Selection |->| |. +------+ . .|Server 2| |Peer/Poll 2|->| and | | Combine |->| Loop | . .| |<-| |. | Cluster | | Algorithm |. |Filter| . .+--------+. +-----------+. | Algorithms |->| |. +------+ . . . ^ . | | +-----------+. | . . . | . | | . | . .+--------+. +-----------+. | | . | . .| |->| |. | | . | . .|Server 3| |Peer/Poll 3|->| | . | . .| |<-| |. | | . | . .+--------+. +-----------+. +------------+ . | . ....................^.........................................|...... | . V . | . +-----+ . +--------------------------------------| VFO | . . +-----+ . . Clock . . Adjust . . Process . ............ Figure 2: Implementation Model
Top   ToC   RFC5905 - Page 11
   These processes operate on a common data structure, called an
   association, which contains the statistics described above along with
   various other data described in Section 9.  A client sends packets to
   one or more servers and then processes returned packets when they are
   received.  The server interchanges source and destination addresses
   and ports, overwrites certain fields in the packet and returns it
   immediately (in the client/server mode) or at some time later (in the
   symmetric modes).  As each NTP message is received, the offset theta
   between the peer clock and the system clock is computed along with
   the associated statistics delta, epsilon, and psi.

   The system process includes the selection, cluster, and combine
   algorithms that mitigate among the various servers and reference
   clocks to determine the most accurate and reliable candidates to
   synchronize the system clock.  The selection algorithm uses Byzantine
   fault detection principles to discard the presumably incorrect
   candidates called "falsetickers" from the incident population,
   leaving only good candidates called "truechimers".  A truechimer is a
   clock that maintains timekeeping accuracy to a previously published
   and trusted standard, while a falseticker is a clock that shows
   misleading or inconsistent time.  The cluster algorithm uses
   statistical principles to find the most accurate set of truechimers.
   The combine algorithm computes the final clock offset by
   statistically averaging the surviving truechimers.

   The clock discipline process is a system process that controls the
   time and frequency of the system clock, here represented as a
   variable frequency oscillator (VFO).  Timestamps struck from the VFO
   close the feedback loop that maintains the system clock time.
   Associated with the clock discipline process is the clock-adjust
   process, which runs once each second to inject a computed time offset
   and maintain constant frequency.  The RMS average of past time offset
   differences represents the nominal error or system clock jitter.  The
   RMS average of past frequency offset differences represents the
   oscillator frequency stability or frequency wander.  These terms are
   given precise interpretation in Section 11.3.

   A client sends messages to each server with a poll interval of 2^tau
   seconds, as determined by the poll exponent tau.  In NTPv4, tau
   ranges from 4 (16 s) to 17 (36 h).  The value of tau is determined by
   the clock discipline algorithm to match the loop-time constant T_c =
   2^tau.  In client/server mode, the server responds immediately;
   however, in symmetric modes, each of two peers manages tau as a
   function of current system offset and system jitter, so they may not
   agree with the same value.  It is important that the dynamic behavior
   of the clock discipline algorithm be carefully controlled in order to
   maintain stability in the NTP subnet at large.  This requires that
Top   ToC   RFC5905 - Page 12
   the peers agree on a common tau equal to the minimum poll exponent of
   both peers.  The NTP protocol includes provisions to properly
   negotiate this value.

   The implementation model includes some means to set and adjust the
   system clock.  The operating system is assumed to provide two
   functions: one to set the time directly, for example, the Unix
   settimeofday() function, and another to adjust the time in small
   increments advancing or retarding the time by a designated amount,
   for example, the Unix adjtime() function.  In this and following
   references, parentheses following a name indicate reference to a
   function rather than a simple variable.  In the intended design the
   clock discipline process uses the adjtime() function if the
   adjustment is less than a designated threshold, and the
   settimeofday() function if above the threshold.  The manner in which
   this is done and the value of the threshold as described in
   Section 10.

6. Data Types

All NTP time values are represented in twos-complement format, with bits numbered in big-endian (as described in Appendix A of [RFC0791]) fashion from zero starting at the left, or high-order, position. There are three NTP time formats, a 128-bit date format, a 64-bit timestamp format, and a 32-bit short format, as shown in Figure 3. The 128-bit date format is used where sufficient storage and word size are available. It includes a 64-bit signed seconds field spanning 584 billion years and a 64-bit fraction field resolving .05 attosecond (i.e., 0.5e-18). For convenience in mapping between formats, the seconds field is divided into a 32-bit Era Number field and a 32-bit Era Offset field. Eras cannot be produced by NTP directly, nor is there need to do so. When necessary, they can be derived from external means, such as the filesystem or dedicated hardware.
Top   ToC   RFC5905 - Page 13
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Seconds              |           Fraction            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                               NTP Short Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Seconds                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Fraction                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             NTP Timestamp Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Offset                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                           Fraction                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              NTP Date Format

                        Figure 3: NTP Time Formats

   The 64-bit timestamp format is used in packet headers and other
   places with limited word size.  It includes a 32-bit unsigned seconds
   field spanning 136 years and a 32-bit fraction field resolving 232
   picoseconds.  The 32-bit short format is used in delay and dispersion
   header fields where the full resolution and range of the other
   formats are not justified.  It includes a 16-bit unsigned seconds
   field and a 16-bit fraction field.

   In the date and timestamp formats, the prime epoch, or base date of
   era 0, is 0 h 1 January 1900 UTC, when all bits are zero.  It should
   be noted that strictly speaking, UTC did not exist prior to 1 January
   1972, but it is convenient to assume it has existed for all eternity,
   even if all knowledge of historic leap seconds has been lost.  Dates
   are relative to the prime epoch; values greater than zero represent
Top   ToC   RFC5905 - Page 14
   times after that date; values less than zero represent times before
   it.  Note that the Era Offset field of the date format and the
   Seconds field of the timestamp format have the same interpretation.

   Timestamps are unsigned values, and operations on them produce a
   result in the same or adjacent eras.  Era 0 includes dates from the
   prime epoch to some time in 2036, when the timestamp field wraps
   around and the base date for era 1 is established.  In either format,
   a value of zero is a special case representing unknown or
   unsynchronized time.  Figure 4 shows a number of historic NTP dates
   together with their corresponding Modified Julian Day (MJD), NTP era,
   and NTP timestamp.

   +-------------+------------+-----+---------------+------------------+
   | Date        | MJD        | NTP | NTP Timestamp | Epoch            |
   |             |            | Era | Era Offset    |                  |
   +-------------+------------+-----+---------------+------------------+
   | 1 Jan -4712 | -2,400,001 | -49 | 1,795,583,104 | 1st day Julian   |
   | 1 Jan -1    | -679,306   | -14 | 139,775,744   | 2 BCE            |
   | 1 Jan 0     | -678,491   | -14 | 171,311,744   | 1 BCE            |
   | 1 Jan 1     | -678,575   | -14 | 202,939,144   | 1 CE             |
   | 4 Oct 1582  | -100,851   | -3  | 2,873,647,488 | Last day Julian  |
   | 15 Oct 1582 | -100,840   | -3  | 2,874,597,888 | First day        |
   |             |            |     |               | Gregorian        |
   | 31 Dec 1899 | 15019      | -1  | 4,294,880,896 | Last day NTP Era |
   |             |            |     |               | -1               |
   | 1 Jan 1900  | 15020      | 0   | 0             | First day NTP    |
   |             |            |     |               | Era 0            |
   | 1 Jan 1970  | 40,587     | 0   | 2,208,988,800 | First day UNIX   |
   | 1 Jan 1972  | 41,317     | 0   | 2,272,060,800 | First day UTC    |
   | 31 Dec 1999 | 51,543     | 0   | 3,155,587,200 | Last day 20th    |
   |             |            |     |               | Century          |
   | 8 Feb 2036  | 64,731     | 1   | 63,104        | First day NTP    |
   |             |            |     |               | Era 1            |
   +-------------+------------+-----+---------------+------------------+

                 Figure 4: Interesting Historic NTP Dates

   Let p be the number of significant bits in the second fraction.  The
   clock resolution is defined as 2^(-p), in seconds.  In order to
   minimize bias and help make timestamps unpredictable to an intruder,
   the non-significant bits should be set to an unbiased random bit
   string.  The clock precision is defined as the running time to read
   the system clock, in seconds.  Note that the precision defined in
   this way can be larger or smaller than the resolution.  The term rho,
   representing the precision used in the protocol, is the larger of the
   two.
Top   ToC   RFC5905 - Page 15
   The only arithmetic operation permitted on dates and timestamps is
   twos-complement subtraction, yielding a 127-bit or 63-bit signed
   result.  It is critical that the first-order differences between two
   dates preserve the full 128-bit precision and the first-order
   differences between two timestamps preserve the full 64-bit
   precision.  However, the differences are ordinarily small compared to
   the seconds span, so they can be converted to floating double format
   for further processing and without compromising the precision.

   It is important to note that twos-complement arithmetic does not
   distinguish between signed and unsigned values (although comparisons
   can take sign into account); only the conditional branch instructions
   do.  Thus, although the distinction is made between signed dates and
   unsigned timestamps, they are processed the same way.  A perceived
   hazard with 64-bit timestamp calculations spanning an era, such as is
   possible in 2036, might result in over-run.  In point of fact, if the
   client is set within 68 years of the server before the protocol is
   started, correct values are obtained even if the client and server
   are in adjacent eras.

   Some time values are represented in exponent format, including the
   precision, time constant, and poll interval.  These are in 8-bit
   signed integer format in log2 (log base 2) seconds.  The only
   arithmetic operations permitted on them are increment and decrement.
   For the purpose of this document and to simplify the presentation, a
   reference to one of these variables by name means the exponentiated
   value, e.g., the poll interval is 1024 s, while reference by name and
   exponent means the actual value, e.g., the poll exponent is 10.

   To convert system time in any format to NTP date and timestamp
   formats requires that the number of seconds s from the prime epoch to
   the system time be determined.  To determine the integer era and
   timestamp given s,

   era = s / 2^(32) and timestamp = s - era * 2^(32),

   which works for positive and negative dates.  To determine s given
   the era and timestamp,

   s = era * 2^(32) + timestamp.

   Converting between NTP and system time can be a little messy, and is
   beyond the scope of this document.  Note that the number of days in
   era 0 is one more than the number of days in most other eras, and
   this won't happen again until the year 2400 in era 3.
Top   ToC   RFC5905 - Page 16
   In the description of state variables to follow, explicit reference
   to integer type implies a 32-bit unsigned integer.  This simplifies
   bounds checks, since only the upper limit needs to be defined.
   Without explicit reference, the default type is 64-bit floating
   double.  Exceptions will be noted as necessary.



(page 16 continued on part 2)

Next Section