draft-ietf-ntp-ntpv4-proto-06.txt   draft-ietf-ntp-ntpv4-proto-07.txt 
NTP WG J. Burbank, Ed. NTP WG J. Burbank, Ed.
Internet-Draft W. Kasch, Ed. Internet-Draft W. Kasch, Ed.
Obsoletes: RFC 4330, RFC 1305 JHU/APL Obsoletes: RFC 4330, RFC 1305 JHU/APL
(if approved) J. Martin, Ed. (if approved) J. Martin, Ed.
Intended status: Standards Track Daedelus Intended status: Standards Track Daedelus
Expires: November 25, 2007 D. Mills Expires: November 2, 2007 D. Mills
U. Delaware U. Delaware
May 24, 2007
Network Time Protocol Version 4 Protocol And Algorithms Specification Network Time Protocol Version 4 Protocol And Algorithms Specification
draft-ietf-ntp-ntpv4-proto-06 draft-ietf-ntp-ntpv4-proto-07
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 25, 2007. This Internet-Draft will expire on November 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The Network Time Protocol (NTP) is widely used to synchronize The Network Time Protocol (NTP) is widely used to synchronize
computer clocks in the Internet. This document describes NTP Version computer clocks in the Internet. This document describes NTP Version
4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3) 4 (NTPv4), which is backwards compatible with NTP Version 3 (NTPv3)
described in RFC 1305, as well as previous versions of the protocol. described in RFC 1305, as well as previous versions of the protocol.
It includes a modified protocol header to accommodate the Internet NTPv4 includes a modified protocol header to accommodate the Internet
Protocol Version 6 address family. NTPv4 includes fundamental Protocol Version 6 address family. NTPv4 includes fundamental
improvements in the mitigation and discipline algorithms which extend improvements in the mitigation and discipline algorithms which extend
the potential accuracy to the tens of microseconds with modern the potential accuracy to the tens of microseconds with modern
workstations and fast LANs. It includes a dynamic server discovery workstations and fast LANs. It includes a dynamic server discovery
scheme, so that in many cases specific server configuration is not scheme, so that in many cases specific server configuration is not
required. It corrects certain errors in the NTPv3 design and required. It corrects certain errors in the NTPv3 design and
implementation and includes an optional extension mechanism. implementation and includes an optional extension mechanism.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
2. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 5 2. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Modes . . . . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Modes . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Simple Network Time Protocol (SNTP) . . . . . . . . . . . 7 3.1. Dynamic Server Discovery . . . . . . . . . . . . . . . . 7
3.2. Dynamic Server Discovery . . . . . . . . . . . . . . . . 8 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Implementation Model . . . . . . . . . . . . . . . . . . . . 10 5. Implementation Model . . . . . . . . . . . . . . . . . . . . 10
6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 17 7. Data Structures . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 17 7.1. Structure Conventions . . . . . . . . . . . . . . . . . . 16
7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 17 7.2. Global Parameters . . . . . . . . . . . . . . . . . . . . 16
7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 18 7.3. Packet Header Variables . . . . . . . . . . . . . . . . . 17
7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 24 7.4. The Kiss-o'-Death Packet . . . . . . . . . . . . . . . . 23
7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 25 7.5. NTP Extension Field Format . . . . . . . . . . . . . . . 24
8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 27 8. On Wire Protocol . . . . . . . . . . . . . . . . . . . . . . 25
9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 31 9. Peer Process . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 31 9.1. Peer Process Variables . . . . . . . . . . . . . . . . . 30
9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 34 9.2. Peer Process Operations . . . . . . . . . . . . . . . . . 32
10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 38 10. Clock Filter Algorithm . . . . . . . . . . . . . . . . . . . 36
11. System Process . . . . . . . . . . . . . . . . . . . . . . . 40 11. System Process . . . . . . . . . . . . . . . . . . . . . . . 38
11.1. System Process Variables . . . . . . . . . . . . . . . . 40 11.1. System Process Variables . . . . . . . . . . . . . . . . 38
11.2. System Process Operations . . . . . . . . . . . . . . . . 41 11.2. System Process Operations . . . . . . . . . . . . . . . . 39
11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 44 11.2.1. Selection Algorithm . . . . . . . . . . . . . . . . 42
11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 45 11.2.2. Cluster Algorithm . . . . . . . . . . . . . . . . . 43
11.2.3. Combine Algorithm . . . . . . . . . . . . . . . . . 46 11.2.3. Combine Algorithm . . . . . . . . . . . . . . . . . 44
11.3. Clock Discipline Algorithm . . . . . . . . . . . . . . . 48 11.3. Clock Discipline Algorithm . . . . . . . . . . . . . . . 46
12. Clock Adjust Process . . . . . . . . . . . . . . . . . . . . 52 12. Clock Adjust Process . . . . . . . . . . . . . . . . . . . . 50
13. Poll Process . . . . . . . . . . . . . . . . . . . . . . . . 52 13. Poll Process . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Poll Process Variables . . . . . . . . . . . . . . . . . 52 13.1. Poll Process Variables . . . . . . . . . . . . . . . . . 50
13.2. Poll Process Operations . . . . . . . . . . . . . . . . . 53 13.2. Poll Process Operations . . . . . . . . . . . . . . . . . 51
14. Security Considerations . . . . . . . . . . . . . . . . . . . 55 14. Simple Network Time Protocol (SNTP) . . . . . . . . . . . . . 53
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 56 15. Security Considerations . . . . . . . . . . . . . . . . . . . 54
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 55
17. Informative References . . . . . . . . . . . . . . . . . . . 56 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
18.1. Informative References . . . . . . . . . . . . . . . . . 56
18.2. Normative References . . . . . . . . . . . . . . . . . . 57
Appendix A. Code Skeleton . . . . . . . . . . . . . . . . . . . 57 Appendix A. Code Skeleton . . . . . . . . . . . . . . . . . . . 57
A.1. Global Definitions . . . . . . . . . . . . . . . . . . . 58 A.1. Global Definitions . . . . . . . . . . . . . . . . . . . 58
A.1.1. Definitions, Constants, Parameters . . . . . . . . . 58 A.1.1. Definitions, Constants, Parameters . . . . . . . . . 58
A.1.2. Packet Data Structures . . . . . . . . . . . . . . . 61 A.1.2. Packet Data Structures . . . . . . . . . . . . . . . 61
A.1.3. Association Data Structures . . . . . . . . . . . . 62 A.1.3. Association Data Structures . . . . . . . . . . . . 62
A.1.4. System Data Structures . . . . . . . . . . . . . . . 64 A.1.4. System Data Structures . . . . . . . . . . . . . . . 64
A.1.5. Local Clock Data Structures . . . . . . . . . . . . 65 A.1.5. Local Clock Data Structures . . . . . . . . . . . . 65
A.1.6. Function Prototypes . . . . . . . . . . . . . . . . 65 A.1.6. Function Prototypes . . . . . . . . . . . . . . . . 65
A.2. Main Program and Utility Routines . . . . . . . . . . . . 66 A.2. Main Program and Utility Routines . . . . . . . . . . . . 66
A.3. Kernel Input/Output Interface . . . . . . . . . . . . . . 69 A.3. Kernel Input/Output Interface . . . . . . . . . . . . . . 69
skipping to change at page 4, line 22 skipping to change at page 4, line 22
described in [1], and functionality expanded from SNTPv4 as described described in [1], and functionality expanded from SNTPv4 as described
in [2] (SNTPv4 is a subset of NTPv4). This document obsoletes [1], in [2] (SNTPv4 is a subset of NTPv4). This document obsoletes [1],
and [2]. While certain minor changes have been made in some protocol and [2]. While certain minor changes have been made in some protocol
header fields, these do not affect the interoperability between NTPv4 header fields, these do not affect the interoperability between NTPv4
and previous versions of NTP and SNTP. and previous versions of NTP and SNTP.
The NTP subnet model includes a number of widely accessible primary The NTP subnet model includes a number of widely accessible primary
time servers synchronized by wire or radio to national standards. time servers synchronized by wire or radio to national standards.
The purpose of the NTP protocol is to convey timekeeping information The purpose of the NTP protocol is to convey timekeeping information
from these primary servers to secondary time servers and clients via from these primary servers to secondary time servers and clients via
both private networks and the public Internet. Crafted algorithms both private networks and the public Internet. Precisely tuned
mitigate errors that may result from network disruptions, server algorithms mitigate errors that may result from network disruptions,
failures and possible hostile actions. Servers and clients are server failures and possible hostile actions. Servers and clients
configured such that values flow towards clients from the primary are configured such that values flow towards clients from the primary
servers at the root via branching secondary servers. servers at the root via branching secondary servers.
The NTPv4 design overcomes significant shortcomings in the NTPv3 The NTPv4 design overcomes significant shortcomings in the NTPv3
design, corrects certain bugs and incorporates new features. In design, corrects certain bugs and incorporates new features. In
particular, expanded NTP timestamp definitions encourage the use of particular, expanded NTP timestamp definitions encourage the use of
the floating double data type throughout the implementation. As a the floating double data type throughout the implementation. As a
result, the time resolution is better than one nanosecond and result, the time resolution is better than one nanosecond and
frequency resolution is less than one nanosecond per second. frequency resolution is less than one nanosecond per second.
Additional improvements include a new clock discipline algorithm Additional improvements include a new clock discipline algorithm
which is more responsive to system clock hardware frequency which is more responsive to system clock hardware frequency
skipping to change at page 5, line 14 skipping to change at page 5, line 14
over from NTPv3, the Autokey public key authentication scheme new to over from NTPv3, the Autokey public key authentication scheme new to
NTPv4 is described in [3]. NTPv4 is described in [3].
The NTP protocol includes modes of operation described in Section 2 The NTP protocol includes modes of operation described in Section 2
using data types described in Section 6 and data structures described using data types described in Section 6 and data structures described
in Section 7. The implementation model described in Section 5 is in Section 7. The implementation model described in Section 5 is
based on a threaded, multi-process architecture, although other based on a threaded, multi-process architecture, although other
architectures could be used as well. The on-wire protocol described architectures could be used as well. The on-wire protocol described
in Section 8 is based on a returnable-time design which depends only in Section 8 is based on a returnable-time design which depends only
on measured clock offsets, but does not require reliable message on measured clock offsets, but does not require reliable message
delivery. The synchronization subnet is a self-organizing, delivery. Reliable message delivery such as TCP[11] can actually
hierarchical, master-slave network with synchronization paths make the delivered NTP packet less reliable since retries would
determined by a shortest-path spanning tree and defined metric. increase the delay value and other errors. The synchronization
While multiple masters (primary servers) may exist, there is no subnet is a self-organizing, hierarchical, master-slave network with
requirement for an election protocol. 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 [4], which contains flow charts This document includes material from [4], which contains flow charts
and equations unsuited for RFC format. There is much additional and equations unsuited for RFC format. There is much additional
information in [5], including an extensive technical analysis and information in [5], including an extensive technical analysis and
performance assessment of the protocol and algorithms in this performance assessment of the protocol and algorithms in this
document. The reference implementation is available at www.ntp.org. document. The reference implementation is available at www.ntp.org.
The remainder of this document contains numerous variables and The remainder of this document contains numerous variables and
mathematical expressions. Some variables take the form of Greek mathematical expressions. Some variables take the form of Greek
characters, which are spelled out by their full case-sensitive name. characters, which are spelled out by their full case-sensitive name.
For example DELTA refers to the uppercase Greek character, while For example DELTA refers to the uppercase Greek character, while
delta refers to the lowercase character. Furthermore, subscripts are delta refers to the lowercase character. Furthermore, subscripts are
denoted with '_', for example theta_i refers to the lowercase Greek denoted with '_', for example theta_i refers to the lowercase Greek
character theta with subscript i, or phonetically theta sub i. 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 (FFO) (pure
number). It is often convenient to express these FFOs in parts per
million (ppm).
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [6]. document are to be interpreted as described in [12].
2. Modes of Operation 2. Modes of Operation
An NTP implementation operates as a primary server, secondary server An NTP implementation operates as a primary server, secondary server
or client. A primary server is synchronized directly to a reference or client. A primary server is synchronized to a reference clock
clock, such as a GPS receiver or telephone modem service. A client directly traceable to UTC (eg, GPS, Galileo, etc). A client
synchronizes to one or more upstream servers, but does not provide synchronizes to one or more upstream servers, but does not provide
synchronization to dependent clients. A secondary server has one or synchronization to dependent clients. A secondary server has one or
more upstream servers and one or more downstream servers or clients. more upstream servers and one or more downstream servers or clients.
All servers and clients who are fully NTPv4 compliance MUST implement All servers and clients who are fully NTPv4 compliant MUST implement
the entire suite of algorithms described in this document. In order the entire suite of algorithms described in this document. In order
to maintain stability in large NTP subnets, secondary servers MUST be to maintain stability in large NTP subnets, secondary servers SHOULD
fully NTPv4 compliant. be fully NTPv4 compliant. Alternative algorithms MAY be used, but
their output MUST be identical to the algorithms described in this
specification, or they MUST be used exclusively in a private network.
3. Protocol Modes 3. Protocol Modes
There are three NTP protocol variants, symmetric, client/server and There are three NTP protocol variants, symmetric, client/server and
broadcast. Each is associated with an association mode as shown in broadcast. Each is associated with an association mode as shown in
Figure 1. In addition, persistent associations are mobilized upon Figure 1. In addition, persistent associations are mobilized upon
startup and are never demobilized. Ephemeral associations are startup and are never demobilized. Ephemeral associations are
mobilized upon the arrival of a packet and are demobilized upon error mobilized upon the arrival of a packet and are demobilized upon error
or timeout. or timeout.
skipping to change at page 6, line 41 skipping to change at page 6, line 49
accept synchronization from them. A server can also be a reference accept synchronization from them. A server can also be a reference
clock driver which obtains time directly from a standard source such clock driver which obtains time directly from a standard source such
as a GPS receiver or telephone modem service. In this varient, as a GPS receiver or telephone modem service. In this varient,
clients pull synchronization from servers. clients pull synchronization from servers.
In the symmetric variant a peer operates as both a server and client In the symmetric variant a peer operates as both a server and client
using either a symmetric active or symmetric passive association. A using either a symmetric active or symmetric passive association. A
persistent symmetric active association sends symmetric active (mode persistent symmetric active association sends symmetric active (mode
1) packets to a symmetric active peer association. Alternatively, an 1) packets to a symmetric active peer association. Alternatively, an
ephemeral symmetric passive association can be mobilized upon arrival ephemeral symmetric passive association can be mobilized upon arrival
of a symmetric active packet with matching no association. That of a symmetric active packet with no matching association. That
association sends symmetric passive (mode 2) packets and persists association sends symmetric passive (mode 2) packets and persists
until error or timeout. Peers both push and pull synchronization to until error or timeout. Peers both push and pull synchronization to
and from each other. For the purposes of this document, a peer and from each other. For the purposes of this document, a peer
operates like a client, so references to client imply peer as well. operates like a client, so references to client imply peer as well.
In the broadcast variant a persistent broadcast server association In the broadcast variant a persistent broadcast server association
sends periodic broadcast server (mode 5) packets which can be sends periodic broadcast server (mode 5) packets which can be
received by multiple clients. Upon reception of a broadcast server received by multiple clients. Upon reception of a broadcast server
packet without a matching association, an ephemeral broadcast client packet without a matching association, an ephemeral broadcast client
(mode 6) association is mobilized and persists until error or (mode 6) association is mobilized and persists until error or
skipping to change at page 7, line 25 skipping to change at page 7, line 33
servers at each lower level are assigned stratum numbers one greater servers at each lower level are assigned stratum numbers one greater
than the preceding level. As the stratum number increases, its than the preceding level. As the stratum number increases, its
accuracy degrades depending on the particular network path and system accuracy degrades depending on the particular network path and system
clock stability. Mean errors, measured by synchronization distances, clock stability. Mean errors, measured by synchronization distances,
increase approximately in proportion to stratum numbers and measured increase approximately in proportion to stratum numbers and measured
roundtrip delay. roundtrip delay.
As a standard practice, timing network topology should be organized As a standard practice, timing network topology should be organized
to avoid timing loops and minimize the synchronization distance. In to avoid timing loops and minimize the synchronization distance. In
NTP the subnet topology is determined using a variant of the Bellman- NTP the subnet topology is determined using a variant of the Bellman-
Ford distributed routing algorithm, which computes the shortest- Ford distributed routing algorithm, which computes the shortest-path
distance spanning tree rooted on the primary servers. As a result of spanning tree rooted on the primary servers. As a result of this
this design, the algorithm automatically reorganizes the subnet, so design, the algorithm automatically reorganizes the subnet, so as to
as to produce the most accurate and reliable time, even when there produce the most accurate and reliable time, even when there are
are failures in the timing network. failures in the timing network.
3.1. Simple Network Time Protocol (SNTP)
Primary servers and clients complying with a subset of NTP, called
the Simple Network Time Protocol (SNTPv4) [2], do not need to
implement the mitigation algorithms described in Section 9 and
following sections. SNTP is intended for primary servers equipped
with a single reference clock, as well as for clients with a single
upstream server and no dependent clients. The fully developed NTPv4
implementation is intended for secondary servers with multiple
upstream servers and multiple downstream servers or clients. Other
than these considerations, NTP and SNTP servers and clients are
completely interoperable and can be mixed and matched in NTP subnets.
An SNTP primary server implementing the on-wire protocol described in
Section 8 has no upstream servers except a single reference clock.
In principle, it is indistinguishable from an NTP primary server that
has the mitigation algorithms and therefore capable of mitigating
between multiple reference clocks.
Upon receiving a client request, an SNTP primary server constructs
and sends the reply packet as described in Figure 2 of Section 9.2.
Note that the dispersion field in the packet header must be updated
as described in Section 5.
+-----------------------------------+
| Packet Variable <-- Variable |
+-----------------------------------+
| x.leap <-- s.leap |
| x.version <-- r.version |
| x.mode <-- 4 |
| x.stratum <-- s.stratum |
| x.poll <-- r.poll |
| x.precision <-- s.precision |
| x.rootdelay <-- s.rootdelay |
| x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid |
| x.reftime <-- s.reftime |
| x.org <-- r.xmt |
| x.rec <-- r.dst |
| x.xmt <-- clock |
| x.keyid <-- r.keyid |
| x.digest <-- md5 digest |
+-----------------------------------+
Figure 2: fast_xmit Packet Header
A SNTP client implementing the on-wire protocol has a single server
and no dependent clients. It can operate with any subset of the NTP
on-wire protocol, the simplest approach using only the transmit
timestamp of the server packet and ignoring all other fields.
However, the additional complexity to implement the full on-wire
protocol is minimal so that a full implementation is encouraged.
3.2. Dynamic Server Discovery 3.1. Dynamic Server Discovery
There are two special associations, manycast client and manycast There are two special associations, manycast client and manycast
server, which provide a dynamic server discovery function. There are server, which provide a dynamic server discovery function. There are
two types of manycast client associations, persistent and ephemeral. two types of manycast client associations, persistent and ephemeral.
The persistent manycast client sends client (mode 3) packets to a The persistent manycast client sends client (mode 3) packets to a
designated IPv4 or IPv6 broadcast or multicast group address. designated IPv4 or IPv6 broadcast or multicast group address.
Designated manycast servers within range of the time-to-live (TTL) Designated manycast servers within range of the time-to-live (TTL)
field in the packet header listen for packets with that address. If field in the packet header listen for packets with that address. If
a server is suitable for synchronization, it returns an ordinary a server is suitable for synchronization, it returns an ordinary
server (mode 4) packet using the client's unicast address. Upon server (mode 4) packet using the client's unicast address. Upon
skipping to change at page 9, line 12 skipping to change at page 8, line 15
A manycast client continues sending packets to search for a minimum A manycast client continues sending packets to search for a minimum
number of associations. It starts with a TTL equal to one and number of associations. It starts with a TTL equal to one and
continuously adding one to it until the minimum number of continuously adding one to it until the minimum number of
associations is made or when the TTL reaches a maximum value. If the associations is made or when the TTL reaches a maximum value. If the
TTL reaches its maximum value and yet not enough associations are TTL reaches its maximum value and yet not enough associations are
mobilized, the client stops transmission for a time-out period to mobilized, the client stops transmission for a time-out period to
clear all associations, and then repeats the search cycle. If a clear all associations, and then repeats the search cycle. If a
minimum number of associations has been mobilized, then the client minimum number of associations has been mobilized, then the client
starts transmitting one packet per time-out period to maintain the starts transmitting one packet per time-out period to maintain the
associations. 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 The ephemeral associations compete among themselves. As new
ephemeral associations are mobilized, the client runs the mitigation ephemeral associations are mobilized, the client runs the mitigation
algorithms described in Section 10 and Section 11.2 for the best algorithms described in Section 10 and Section 11.2 for the best
candidates out of the population, the remaining ephemeral candidates out of the population, the remaining ephemeral
associations are timed out and demobilized. In this way the associations are timed out and demobilized. In this way the
population includes only the best and freshest candidates to population includes only the best candidates that have most recently
discipline the system clock. The reference implementation includes responded with an NTP packet to discipline the system clock.
intricate means to do this, but these are beyond the scope of this
document.
4. Definitions 4. Definitions
A number of technical terms are defined in this section. A timescale 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 is a frame of reference where time is expressed as the value of a
monotonically increasing binary counter with an indefinite number of monotonically increasing binary counter with an indefinite number of
bits. It counts in seconds and fractions of a second, when a decimal bits. It counts in seconds and fractions of a second, when a decimal
point is employed. The Coordinated Universal Time (UTC) timescale point is employed. The Coordinated Universal Time (UTC) timescale is
represents mean solar time as disseminated by national standards defined by ITU-R TF.460[6]. Under the auspices of the Metre
laboratories. The system time is represented by the system clock Convention of 1865, in 1975 the CGPM[7] strongly endorsed the use of
maintained by the hardware and operating system. The goal of the NTP UTC as the basis for civil time.
algorithms is to minimize both the time difference and frequency
difference between UTC and the system clock. When these differences The Coordinated Universal Time (UTC) timescale represents mean solar
have been reduced below nominal tolerances, the system clock is said time as disseminated by national standards laboratories. The system
to be synchronized to UTC. 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.
The date of an event is the UTC time at which the event takes place. The date of an event is the UTC time at which the event takes place.
Dates are ephemeral values designated with upper case T. Running time Dates are ephemeral values designated with upper case T. Running time
is another timescale that is coincident to the synchronization is another timescale that is coincident to the synchronization
function of the NTP program. function of the NTP program.
A timestamp T(t) represents either the UTC date or time offset from 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 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 from the context. Let T(t) be the time offset, R(t) the frequency
offset, D(t) the aging rate (first derivative of R(t) with respect to offset, D(t) the aging rate (first derivative of R(t) with respect to
skipping to change at page 10, line 28 skipping to change at page 9, line 36
maximum-likelihood time offset of the server clock relative to the maximum-likelihood time offset of the server clock relative to the
system clock. The delay (delta) represents the round trip delay system clock. The delay (delta) represents the round trip delay
between the client and server. The dispersion (epsilon) represents between the client and server. The dispersion (epsilon) represents
the maximum error inherent in the measurement. It increases at a the maximum error inherent in the measurement. It increases at a
rate equal to the maximum disciplined system clock frequency rate equal to the maximum disciplined system clock frequency
tolerance (PHI), typically 15 PPM. The jitter (psi) is defined as tolerance (PHI), typically 15 PPM. The jitter (psi) is defined as
the root-mean-square (RMS) average of the most recent offset the root-mean-square (RMS) average of the most recent offset
differences, represents the nominal error in estimating the offset. differences, represents the nominal error in estimating the offset.
While the theta, delta, epsilon, and psi statistics represent While the theta, delta, epsilon, and psi statistics represent
measurements of the system clock relative to the each server clock measurements of the system clock relative to each server clock
separately, the NTP protocol includes mechanisms to combine the separately, the NTP protocol includes mechanisms to combine the
statistics of several servers to more accurately discipline and statistics of several servers to more accurately discipline and
calibrate the system clock. The system offset (THETA) represents the calibrate the system clock. The system offset (THETA) represents the
maximum-likelihood offset estimate for the server population. The maximum-likelihood offset estimate for the server population. The
system jitter (PSI) represents the nominal error in estimating the system jitter (PSI) represents the nominal error in estimating the
system offset. The delta and epsilon statistics are accumulated at system offset. The delta and epsilon statistics are accumulated at
each stratum level from the reference clock to produce the root delay each stratum level from the reference clock to produce the root delay
(DELTA) and root dispersion (EPSILON) statistics. The (DELTA) and root dispersion (EPSILON) statistics. The
synchronization distance (LAMBDA) equal to EPSILON + DELTA / 2 synchronization distance (LAMBDA) equal to EPSILON + DELTA / 2
represents the maximum error due all causes. The detailed represents the maximum error due all causes. The detailed
formulations of these statistics are given in Section 11.2. They are formulations of these statistics are given in Section 11.2. They are
available to the dependent applications in order to assess the available to the dependent applications in order to assess the
performance of the synchronization function. performance of the synchronization function.
5. Implementation Model 5. Implementation Model
Figure 3 shows the architecture of a typical, multi-threaded Figure 2 shows the architecture of a typical, multi-threaded
implementation. It includes two processes dedicated to each server, implementation. It includes two processes dedicated to each server,
a peer process to receive messages from the server or reference clock a peer process to receive messages from the server or reference clock
and a poll process to transmit messages to the server or reference and a poll process to transmit messages to the server or reference
clock. clock.
..................................................................... .....................................................................
. Remote . Peer/Poll . System . Clock . . Remote . Peer/Poll . System . Clock .
. Servers . Processes . Process .Discipline. . Servers . Processes . Process .Discipline.
. . . . Process . . . . . Process .
.+--------+. +-----------+. +------------+ . . .+--------+. +-----------+. +------------+ . .
skipping to change at page 11, line 38 skipping to change at page 10, line 46
....................^.........................................|...... ....................^.........................................|......
| . V . | . V .
| . +-----+ . | . +-----+ .
+--------------------------------------| VFO | . +--------------------------------------| VFO | .
. +-----+ . . +-----+ .
. Clock . . Clock .
. Adjust . . Adjust .
. Process . . Process .
............ ............
Figure 3: Implementation Model Figure 2: Implementation Model
These processes operate on a common data structure, called an These processes operate on a common data structure, called an
association, which contains the statistics described above along with association, which contains the statistics described above along with
various other data described in Section 9. A client sends packets to various other data described in Section 9. A client sends packets to
one or more servers and then processes returned packets when they are one or more servers and then processes returned packets when they are
received. The server interchanges source and destination addresses received. The server interchanges source and destination addresses
and ports, overwrites certain fields in the packet and returns it and ports, overwrites certain fields in the packet and returns it
immediately (in the client/server mode) or at some time later (in the immediately (in the client/server mode) or at some time later (in the
symmetric modes). As each NTP message is received, the offset theta symmetric modes). As each NTP message is received, the offset theta
between the peer clock and the system clock is computed along with between the peer clock and the system clock is computed along with
the associated statistics delta, epsilon and psi. the associated statistics delta, epsilon and psi.
The system process includes the selection, cluster and combine The system process includes the selection, cluster and combine
algorithms that mitigate among the various servers and reference algorithms that mitigate among the various servers and reference
clocks to determine the most accurate and reliable candidates to clocks to determine the most accurate and reliable candidates to
synchronize the system clock. The selection algorithm uses Byzantine synchronize the system clock. The selection algorithm uses Byzantine
principles to discard the presumably incorrect candidates called fault detection principles to discard the presumably incorrect
"falsetickers" from the incident population, leaving only good candidates called "falsetickers" from the incident population,
candidates called "truechimers". A truechimer is a clock that leaving only good candidates called "truechimers". A truechimer is a
maintains timekeeping accuracy to a previously published and trusted clock that maintains timekeeping accuracy to a previously published
standard, while a falseticker is a clock that shows misleading or and trusted standard, while a falseticker is a clock that shows
inconsistent time. The cluster algorithm uses statistical principles misleading or inconsistent time. The cluster algorithm uses
to find the most accurate set of truechimers. The combine algorithm statistical principles to find the most accurate set of truechimers.
computes the final clock offset by statistically averaging the The combine algorithm computes the final clock offset by
surviving truechimers. statistically averaging the surviving truechimers.
The clock discipline process is a system process that controls the The clock discipline process is a system process that controls the
time and frequency of the system clock, here represented as a time and frequency of the system clock, here represented as a
variable frequency oscillator (VFO). Timestamps struck from the VFO variable frequency oscillator (VFO). Timestamps struck from the VFO
close the feedback loop which maintains the system clock time. close the feedback loop which maintains the system clock time.
Associated with the clock discipline process is the clock adjust Associated with the clock discipline process is the clock adjust
process, which runs once each second to inject a computed time offset process, which runs once each second to inject a computed time offset
and maintain constant frequency. The RMS average of past time offset and maintain constant frequency. The RMS average of past time offset
differences represents the nominal error or system clock jitter. The differences represents the nominal error or system clock jitter. The
RMS average of past frequency offset differences represents the RMS average of past frequency offset differences represents the
oscillator frequency stability or frequency wander. These terms are oscillator frequency stability or frequency wander. These terms are
given precise interpretation in Section 11.2. given precise interpretation in Section 11.3.
A client sends messages to each server with a poll interval of 2^tau 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 seconds, as determined by the poll exponent tau. In NTPv4, tau
ranges from 4 (16 s) through 17 (36 h). The value of tau is ranges from 4 (16 s) through 17 (36 h). The value of tau is
determined by the clock discipline algorithm to match the loop time determined by the clock discipline algorithm to match the loop time
constant T_c = 2^tau. In client/server mode the server responds constant T_c = 2^tau. In client/server mode the server responds
immediately; however, in symmetric modes each of two peers manages immediately; however, in symmetric modes each of two peers manages
tau as a function of current system offset and system jitter, so may tau as a function of current system offset and system jitter, so may
not agree with the same value. It is important that the dynamic not agree with the same value. It is important that the dynamic
behavior of the clock discipline algorithm be carefully controlled in behavior of the clock discipline algorithm be carefully controlled in
skipping to change at page 13, line 11 skipping to change at page 12, line 19
function rather than a simple variable. In the intended design the function rather than a simple variable. In the intended design the
clock discipline process uses the adjtime() function if the clock discipline process uses the adjtime() function if the
adjustment is less than a designated threshold, and the adjustment is less than a designated threshold, and the
settimeofday() function if above the threshold. The manner in which settimeofday() function if above the threshold. The manner in which
this is done and the value of the threshold as described in this is done and the value of the threshold as described in
Section 10. Section 10.
6. Data Types 6. Data Types
All NTP time values are represented in twos-complement format, with All NTP time values are represented in twos-complement format, with
bits numbered in big-endian (as described in Appendix A of [7]) bits numbered in big-endian (as described in Appendix A of [13])
fashion from zero starting at the left, or high-order, position. 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 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 4. 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 The 128-bit date format is used where sufficient storage and word
size are available. It includes a 64-bit signed seconds field size are available. It includes a 64-bit signed seconds field
spanning 584 billion years and a 64-bit fraction field resolving .05 spanning 584 billion years and a 64-bit fraction field resolving .05
attosecond (i.e., 0.5e-18). For convenience in mapping between attosecond (i.e., 0.5e-18). For convenience in mapping between
formats, the seconds field is divided into a 32-bit Era Number field 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 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 directly, nor is there need to do so. When necessary, they can be
derived from external means, such as the filesystem or dedicated derived from external means, such as the filesystem or dedicated
hardware. hardware.
skipping to change at page 14, line 37 skipping to change at page 13, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Era Offset | | Era Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Fraction | | Fraction |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NTP Date Format NTP Date Format
Figure 4: NTP Time Formats Figure 3: NTP Time Formats
The 64-bit timestamp format is used in packet headers and other The 64-bit timestamp format is used in packet headers and other
places with limited word size. It includes a 32-bit unsigned seconds places with limited word size. It includes a 32-bit unsigned seconds
field spanning 136 years and a 32-bit fraction field resolving 232 field spanning 136 years and a 32-bit fraction field resolving 232
picoseconds. The 32-bit short format is used in delay and dispersion picoseconds. The 32-bit short format is used in delay and dispersion
header fields where the full resolution and range of the other header fields where the full resolution and range of the other
formats are not justified. It includes a 16-bit unsigned seconds formats are not justified. It includes a 16-bit unsigned seconds
field and a 16-bit fraction field. field and a 16-bit fraction field.
In the date and timestamp formats the prime epoch, or base date of In the date and timestamp formats the prime epoch, or base date of
skipping to change at page 15, line 13 skipping to change at page 14, line 13
are relative to the prime epoch; values greater than zero represent are relative to the prime epoch; values greater than zero represent
times after that date; values less than zero represent times before times after that date; values less than zero represent times before
it. Note that the Era Offset field of the date format and the it. Note that the Era Offset field of the date format and the
Seconds field of the timestamp format have the same interpretation. Seconds field of the timestamp format have the same interpretation.
Timestamps are unsigned values and operations on them produce a Timestamps are unsigned values and operations on them produce a
result in the same or adjacent eras. Era 0 includes dates from the 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 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 around and the base date for era 1 is established. In either format
a value of zero is a special case representing unknown or a value of zero is a special case representing unknown or
unsynchronized time. Figure 5 shows a number of historic NTP dates unsynchronized time. Figure 4 shows a number of historic NTP dates
together with their corresponding Modified Julian Day (MJD), NTP era together with their corresponding Modified Julian Day (MJD), NTP era
and NTP timestamp. and NTP timestamp.
+-------------+------------+-----+---------------+------------------+ +-------------+------------+-----+---------------+------------------+
| Year | MJD | NTP | NTP Timestamp | Epoch | | Date | MJD | NTP | NTP Timestamp | Epoch |
| | | Era | Era Offset | | | | | Era | Era Offset | |
+-------------+------------+-----+---------------+------------------+ +-------------+------------+-----+---------------+------------------+
| 1 Jan -4712 | -2,400,001 | -49 | 1,795,583,104 | 1st day Julian | | 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 -1 | -679,306 | -14 | 139,775,744 | 2 BCE |
| 1 Jan 0 | -678,491 | -14 | 171,311,744 | 1 BCE | | 1 Jan 0 | -678,491 | -14 | 171,311,744 | 1 BCE |
| 1 Jan 1 | -678,575 | -14 | 202,939,144 | 1 CE | | 1 Jan 1 | -678,575 | -14 | 202,939,144 | 1 CE |
| 4 Oct 1582 | -100,851 | -3 | 2,873,647,488 | Last day Julian | | 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 | | 15 Oct 1582 | -100,840 | -3 | 2,874,597,888 | First day |
| | | | | Gregorian | | | | | | Gregorian |
| 31 Dec 1899 | 15019 | -1 | 4,294,880,896 | Last day NTP Era | | 31 Dec 1899 | 15019 | -1 | 4,294,880,896 | Last day NTP Era |
skipping to change at page 15, line 40 skipping to change at page 14, line 40
| 1 Jan 1900 | 15020 | 0 | 0 | First day NTP | | 1 Jan 1900 | 15020 | 0 | 0 | First day NTP |
| | | | | Era 0 | | | | | | Era 0 |
| 1 Jan 1970 | 40,587 | 0 | 2,208,988,800 | First day UNIX | | 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 | | 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 | | 31 Dec 1999 | 51,543 | 0 | 3,155,587,200 | Last day 20th |
| | | | | Century | | | | | | Century |
| 8 Feb 2036 | 64,731 | 1 | 63,104 | First day NTP | | 8 Feb 2036 | 64,731 | 1 | 63,104 | First day NTP |
| | | | | Era 1 | | | | | | Era 1 |
+-------------+------------+-----+---------------+------------------+ +-------------+------------+-----+---------------+------------------+
Figure 5: Interesting Historic NTP Dates Figure 4: Interesting Historic NTP Dates
Let p be the number of significant bits in the second fraction. The Let p be the number of significant bits in the second fraction. The
clock resolution is defined 2^(-p), in seconds. In order to minimize clock resolution is defined 2^(-p), in seconds. In order to minimize
bias and help make timestamps unpredictable to an intruder, the non- bias and help make timestamps unpredictable to an intruder, the non-
significant bits should be set to an unbiased random bit string. The 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 precision is defined as the running time to read the system
clock, in seconds. Note that the precision defined in this way can clock, in seconds. Note that the precision defined in this way can
be larger or smaller than the resolution. The term rho, representing be larger or smaller than the resolution. The term rho, representing
the precision used in the protocol, is the larger of the two. the precision used in the protocol, is the larger of the two.
The only arithmetic operation permitted on dates and timestamps is The only arithmetic operation permitted on dates and timestamps is
twos-complement subtraction, yielding a 127-bit or 63-bit signed twos-complement subtraction, yielding a 127-bit or 63-bit signed
result. It is critical that the first-order differences between two result. It is critical that the first-order differences between two
dates preserve the full 128-bit precision and the first-order dates preserve the full 128-bit precision and the first-order
differences between two timestamps preserve the full 64-bit differences between two timestamps preserve the full 64-bit
precision. However, the differences are ordinarily small compared to precision. However, the differences are ordinarily small compared to
the seconds span, so they can be converted to floating double format the seconds span, so they can be converted to floating double format
for further processing and without compromising the precision. for further processing and without compromising the precision.
It is important to note that twos-complement arithmetic does not know It is important to note that twos-complement arithmetic does not
the difference between signed and unsigned values; only the distinguish between signed and unsigned values (although comparisons
conditional branch instructions do. Thus, although the distinction can take sign into account); only the conditional branch instructions
is made between signed dates and unsigned timestamps, they are do. Thus, although the distinction is made between signed dates and
processed the same way. A perceived hazard with 64-bit timestamp unsigned timestamps, they are processed the same way. A perceived
calculations spanning an era, such as possible in 2036, might result hazard with 64-bit timestamp calculations spanning an era, such as
in incorrect values. In point of fact, if the client is set within possible in 2036, might result in over-run. In point of fact, if the
68 years of the server before the protocol is started, correct values client is set within 68 years of the server before the protocol is
are obtained even if the client and server are in adjacent eras. 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 Some time values are represented in exponent format, including the
precision, time constant and poll interval. These are in 8-bit precision, time constant and poll interval. These are in 8-bit
signed integer format in log2 (log to the base 2) seconds. The only signed integer format in log2 (log base 2) seconds. The only
arithmetic operations permitted on them are increment and decrement. arithmetic operations permitted on them are increment and decrement.
For the purpose of this document and to simplify the presentation, a For the purpose of this document and to simplify the presentation, a
reference to one of these variables by name means the exponentiated 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 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. exponent means the actual value, e.g., the poll exponent is 10.
To convert system time in any format to NTP date and timestamp 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 formats requires that the number of seconds s from the prime epoch to
the system time be determined. To determine the integer era and the system time be determined. To determine the integer era and
timestamp given s, timestamp given s,
era = s / 2^(32) and timestamp = s - era * 2^(32), era = s / 2^(32) and timestamp = s - era * 2^(32),
which works for positive and negative dates. To determine s given which works for positive and negative dates. To determine s given
the era and timestamp, the era and timestamp,
s = era * 2^(32) + timestamp. s = era * 2^(32) + timestamp.
Converting between NTP and system time can be a little messy, but Converting between NTP and system time can be a little messy, and
beyond the scope of this document. Note that the number of days in 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 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. won't happen again until the year 2400 in era 3.
In the description of state variables to follow, explicit reference In the description of state variables to follow, explicit reference
to integer type implies a 32-bit unsigned integer. This simplifies to integer type implies a 32-bit unsigned integer. This simplifies
bounds checks, since only the upper limit needs to be defined. bounds checks, since only the upper limit needs to be defined.
Without explicit reference, the default type is 64-bit floating Without explicit reference, the default type is 64-bit floating
double. Exceptions will be noted as necessary. double. Exceptions will be noted as necessary.
7. Data Structures 7. Data Structures
The NTP protocol state machines described in following sections are The NTP protocol state machines described in the following sections
defined using state variables and code fragments defined in are defined using state variables and code fragments defined in
Appendix A. State variables are separated into classes according to Appendix A. State variables are separated into classes according to
their function in packet headers, peer and poll processes, the system their function in packet headers, peer and poll processes, the system
process and the clock discipline process. Packet variables represent process and the clock discipline process. Packet variables represent
the NTP header values in transmitted and received packets. Peer and the NTP header values in transmitted and received packets. Peer and
poll variables represent the contents of the association for each poll variables represent the contents of the association for each
server separately. System variables represent the state of the server separately. System variables represent the state of the
server as seen by its dependent clients. Clock discipline variables server as seen by its dependent clients. Clock discipline variables
represent the internal workings of the clock discipline algorithm. represent the internal workings of the clock discipline algorithm.
Additional parameters and variable classes are defined in Appendix A. Additional parameters and variable classes are defined in Appendix A.
7.1. Structure Conventions 7.1. Structure Conventions
In order to distinguish between different variables of the same name In order to distinguish between different variables of the same name
but used in different processes, the naming convention summarized in but used in different processes, the naming convention summarized in
Figure 6 is adopted. A receive packet variable v is a member of the Figure 5 is adopted. A receive packet variable v is a member of the
packet structure r with fully qualified name r.v. In a similar packet structure r with fully qualified name r.v. In a similar
manner x.v is a transmit packet variable, p.v is a peer variable, s.v manner x.v is a transmit packet variable, p.v is a peer variable, s.v
is a system variable and c.v is a clock discipline variable. There is a system variable and c.v is a clock discipline variable. There
is a set of peer variables for each association; there is only one is a set of peer variables for each association; there is only one
set of system and clock variables. set of system and clock variables.
+------+---------------------------------+ +------+---------------------------------+
| Name | Description | | Name | Description |
+------+---------------------------------+ +------+---------------------------------+
| r. | receive packet header variable | | r. | receive packet header variable |
| x. | transmit packet header variable | | x. | transmit packet header variable |
| p. | peer/poll variable | | p. | peer/poll variable |
| s. | system variable | | s. | system variable |
| c. | clock discipline variable | | c. | clock discipline variable |
+------+---------------------------------+ +------+---------------------------------+
Figure 6: Prefix Conventions Figure 5: Prefix Conventions
7.2. Global Parameters 7.2. Global Parameters
In addition to the variable classes a number of global parameters are In addition to the variable classes a number of global parameters are
defined in this document, including those shown with values in defined in this document, including those shown with values in
Figure 7. Figure 6.
+-----------+-------+----------------------------------+ +-----------+-------+----------------------------------+
| Name | Value | Description | | Name | Value | Description |
+-----------+-------+----------------------------------+ +-----------+-------+----------------------------------+
| PORT | 123 | NTP port number | | PORT | 123 | NTP port number |
| VERSION | 4 | version number | | VERSION | 4 | version number |
| TOLERANCE | 15e-6 | frequency tolerance PHI (s/s) | | TOLERANCE | 15e-6 | frequency tolerance PHI (s/s) |
| MINPOLL | 4 | minimum poll exponent (16 s) | | MINPOLL | 4 | minimum poll exponent (16 s) |
| MAXPOLL | 17 | maximum poll exponent (36 h) | | MAXPOLL | 17 | maximum poll exponent (36 h) |
| MAXDISP | 16 | maximum dispersion (16 s) | | MAXDISP | 16 | maximum dispersion (16 s) |
| MINDISP | .005 | minimum dispersion increment (s) | | MINDISP | .005 | minimum dispersion increment (s) |
| MAXDIST | 1 | distance threshold (1 s) | | MAXDIST | 1 | distance threshold (1 s) |
| MAXSTRAT | 16 | maximum stratum number | | MAXSTRAT | 16 | maximum stratum number |
+-----------+-------+----------------------------------+ +-----------+-------+----------------------------------+
Figure 7: Global Parameters Figure 6: Global Parameters
While these are the only global parameters needed in this document, a While these are the only global parameters needed in this document, a
larger collection is necessary in the skeleton and larger still for larger collection is necessary in the skeleton and larger still for
any implementation. Appendix A.1.1 contains those used by the any implementation. Appendix A.1.1 contains those used by the
skeleton for the mitigation algorithms, clock discipline algorithm skeleton for the mitigation algorithms, clock discipline algorithm
and related implementation-dependent functions. Some of these and related implementation-dependent functions. Some of these
parameter values are cast in stone, like the NTP port number assigned parameter values are cast in stone, like the NTP port number assigned
by the IANA and the version number assigned NTPv4 itself. Others by the IANA and the version number assigned NTPv4 itself. Others
like the frequency tolerance (also called PHI), involve an assumption like the frequency tolerance (also called PHI), involve an assumption
about the worst case behavior of a system clock once synchronized and about the worst case behavior of a system clock once synchronized and
skipping to change at page 18, line 43 skipping to change at page 17, line 43
While shown with fixed values in this document, some implementations While shown with fixed values in this document, some implementations
may make them variables adjustable by configuration commands. For may make them variables adjustable by configuration commands. For
instance, the reference implementation computes the value of instance, the reference implementation computes the value of
PRECISION as log2 of the minimum time in several iterations to read PRECISION as log2 of the minimum time in several iterations to read
the system clock. the system clock.
7.3. Packet Header Variables 7.3. Packet Header Variables
The most important state variables from an external point of view are The most important state variables from an external point of view are
the packet header variables described in Figure 8 and below. The NTP the packet header variables described in Figure 7 and below. The NTP
packet header consists of an integral number of 32-bit (4 octet) packet header consists of an integral number of 32-bit (4 octet)
words in network byte order. The packet format consists of three words in network byte order. The packet format consists of three
components, the header itself, one or more optional extension fields components, the header itself, one or more optional extension fields
and an optional message authentication code (MAC). The header and an optional message authentication code (MAC). The header
component is identical to the NTPv3 header and previous versions. component is identical to the NTPv3 header and previous versions.
The optional extension fields are used by the Autokey public key The optional extension fields are used by the Autokey public key
cryptographic algorithms described in [3]. The optional MAC is used cryptographic algorithms described in [3]. The optional MAC is used
by both Autokey and the symmetric key cryptographic algorithm by both Autokey and the symmetric key cryptographic algorithm
described in this report. described in this report.
skipping to change at page 19, line 23 skipping to change at page 18, line 23
| precision | rho | precision exponent | | precision | rho | precision exponent |
| rootdelay | delta_r | root delay | | rootdelay | delta_r | root delay |
| rootdisp | epsilon_r | root dispersion | | rootdisp | epsilon_r | root dispersion |
| refid | refid | reference ID | | refid | refid | reference ID |
| reftime | reftime | reference timestamp | | reftime | reftime | reference timestamp |
| org | T1 | origin timestamp | | org | T1 | origin timestamp |
| rec | T2 | receive timestamp | | rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp | | xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp | | dst | T4 | destination timestamp |
| keyid | keyid | key ID | | keyid | keyid | key ID |
| digest | digest | message digest | | MAC | MAC | message digest |
+-----------+------------+-----------------------+ +-----------+------------+-----------------------+
Figure 8: Packet Header Variables Figure 7: Packet Header Variables
The NTP packet header follows the UDP and IP headers and the physical The NTP packet is a UDP datagram[14]. Some fields use multiple words
header specific to the underlying transport network. Some fields use and others are packed in smaller fields within a word. The NTP
multiple words and others are packed in smaller fields within a word. packet header shown in Figure 8 has 12 words followed by optional
The NTP packet header shown in Figure 9 has 12 words followed by extension fields and finally an optional message authentication code
optional extension fields and finally an optional message (MAC) consisting of the key identifier field and message digest
authentication code (MAC) consisting of the key identifier field and field.
message digest field.
0 1 2 3 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 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 | VN |Mode | Stratum | Poll | Precision | |LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay | | Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion | | Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 33 skipping to change at page 19, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Receive Timestamp (64) + + Receive Timestamp (64) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Transmit Timestamp (64) + + Transmit Timestamp (64) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Extension Field 1 (variable) + . .
. Extension Field 1 (variable) .
. .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Extension Field 2 (variable) + . .
. Extension Field 2 (variable) .
. .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier | | Key Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Message Digest (128) | | MAC (128) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Packet Header Format Figure 8: Packet Header Format
The extension fields are used to add optional capabilities, for The extension fields are used to add optional capabilities, for
example, the Autokey security protocol [3]. The extension field example, the Autokey security protocol [3]. The extension field
format is presented in order that the packet can be parsed without format is presented in order that the packet can be parsed without
knowledge of the extension field functions. The MAC is used by both knowledge of the extension field functions. The MAC is used by both
Autokey and the symmetric key authentication scheme described in Autokey and the symmetric key authentication scheme described in
Appendix A. Appendix A.
A list of the packet header variables is shown in Figure 8 and A list of the packet header variables is shown in Figure 7 and
described in detail below. Except for a minor variation when using described in detail below. Except for a minor variation when using
the IPv6 address family, these fields are backwards compatible with the IPv6 address family, these fields are backwards compatible with
NTPv3. The packet header fields apply to both transmitted packets (x NTPv3. The packet header fields apply to both transmitted packets (x
prefix) and received packets (r prefix). In Figure 9 the size of prefix) and received packets (r prefix). In Figure 8 the size of
some multiple-word fields is shown in bits if not the default 32 some multiple-word fields is shown in bits if not the default 32
bits. The header extends from the beginning of the packet to the end bits. The basic header extends from the beginning of the packet to
of the Transmit Timestamp field. the end of the Transmit Timestamp field.
The fields and associated packet variables (in parentheses) are The fields and associated packet variables (in parentheses) are
interpreted as follows: interpreted as follows:
LI Leap Indicator (leap): 2-bit integer warning of an impending leap LI Leap Indicator (leap): 2-bit integer warning of an impending leap
second to be inserted or deleted in the last minute of the current second to be inserted or deleted in the last minute of the current
month with values defined in Figure 10. month with values defined in Figure 9.
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| Value | Meaning | | Value | Meaning |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
| 0 | no warning | | 0 | no warning |
| 1 | last minute of the day has 61 seconds | | 1 | last minute of the day has 61 seconds |
| 2 | last minute of the day has 59 seconds | | 2 | last minute of the day has 59 seconds |
| 3 | alarm condition (the clock is not synchronized) | | 3 | alarm condition (the clock is not synchronized) |
+-------+-------------------------------------------------+ +-------+-------------------------------------------------+
Figure 10: Leap Indicator Figure 9: Leap Indicator
VN Version Number (version): 3-bit integer representing the NTP VN Version Number (version): 3-bit integer representing the NTP
version number, currently 4. version number, currently 4.
Mode (mode): 3-bit integer representing the mode, with values defined Mode (mode): 3-bit integer representing the mode, with values defined
in Figure 11. in Figure 10.
+-------+--------------------------+ +-------+--------------------------+
| Value | Meaning | | Value | Meaning |
+-------+--------------------------+ +-------+--------------------------+
| 0 | reserved | | 0 | reserved |
| 1 | symmetric active | | 1 | symmetric active |
| 2 | symmetric passive | | 2 | symmetric passive |
| 3 | client | | 3 | client |
| 4 | server | | 4 | server |
| 5 | broadcast | | 5 | broadcast |
| 6 | NTP control message | | 6 | NTP control message |
| 7 | reserved for private use | | 7 | reserved for private use |
+-------+--------------------------+ +-------+--------------------------+
Figure 11: Association Modes Figure 10: Association Modes
Stratum (stratum): 8-bit integer representing the stratum, with Stratum (stratum): 8-bit integer representing the stratum, with
values defined in Figure 12. values defined in Figure 11.
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
| Value | Meaning | | Value | Meaning |
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
| 0 | unspecified or invalid | | 0 | unspecified or invalid |
| 1 | primary server (e.g., equipped with a GPS receiver) | | 1 | primary server (e.g., equipped with a GPS receiver) |
| 2-15 | secondary server (via NTP) | | 2-15 | secondary server (via NTP) |
| 16-255 | undefined | | 16 | unsynchronized |
| 17-255 | reserved |
+--------+-----------------------------------------------------+ +--------+-----------------------------------------------------+
Figure 12: Packet Stratum Figure 11: Packet Stratum
It is customary to map the stratum value 0 in received packets to It is customary to map the stratum value 0 in received packets to
MAXSTRAT (16) in the peer variable p.stratum and to map p.stratum MAXSTRAT (16) in the peer variable p.stratum and to map p.stratum
values of MAXSTRAT or greater to 0 in transmitted packets. This values of MAXSTRAT or greater to 0 in transmitted packets. This
allows reference clocks, which normally appear at stratum 0, to be allows reference clocks, which normally appear at stratum 0, to be
conveniently mitigated using the same algorithms used for external conveniently mitigated using the same algorithms used for external
sources. sources (See Appendix A.5.5.1).
Poll: 8-bit signed integer representing the maximum interval between Poll: 8-bit signed integer representing the maximum interval between
successive messages, in log2 seconds. Suggested default limits for successive messages, in log2 seconds. Suggested default limits for
minimum and maximum poll intervals are 6 and 10, respectively. minimum and maximum poll intervals are 6 and 10, respectively.
Precision: 8-bit signed integer representing the precision of the Precision: 8-bit signed integer representing the precision of the
system clock, in log2 seconds. For instance a value of -18 system clock, in log2 seconds. For instance a value of -18
corresponds to a precision of about one microsecond. The precision corresponds to a precision of about one microsecond. The precision
can be determined when the service first starts up as the minimum can be determined when the service first starts up as the minimum
time of several iterations to read the system clock. time of several iterations to read the system clock.
Root Delay (rootdelay): Total round trip delay to the reference Root Delay (rootdelay): Total round trip delay to the reference
clock, in NTP short format. clock, in NTP short format.
Root Dispersion (rootdisp): Total dispersion to the reference clock, Root Dispersion (rootdisp): Total dispersion to the reference clock,
in NTP short format. in NTP short format.
Reference ID (refid): 32-bit code identifying the particular server Reference ID (refid): 32-bit code identifying the particular server
or reference clock. The interpretation depends on the value in the or reference clock. The interpretation depends on the value in the
stratum field. For packet stratum 0 (unspecified or invalid) this is stratum field. For packet stratum 0 (unspecified or invalid) this is
a four-character ASCII string, called the kiss code, used for a four-character ASCII[15] string, called the kiss code, used for
debugging and monitoring purposes. For stratum 1 (reference clock) debugging and monitoring purposes. For stratum 1 (reference clock)
this is a four-octet, left-justified, zero-padded ASCII string this is a four-octet, left-justified, zero-padded ASCII string
assigned to the reference clock. While not specifically enumerated assigned to the reference clock. While not specifically enumerated
in this document, the identifiers in Figure 13 have been used as in this document, the identifiers in Figure 12 have been used as
ASCII identifiers: ASCII identifiers:
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| ID | Clock Source | | ID | Clock Source |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
| GOES | Geosynchronous Orbit Environment Satellite | | GOES | Geosynchronous Orbit Environment Satellite |
| GPS | Global Position System | | GPS | Global Position System |
| GAL | Galileo Positioning System | | GAL | Galileo Positioning System |
| PPS | Generic pulse-per-second | | PPS | Generic pulse-per-second |
| IRIG | Inter-Range Instrumentation Group | | IRIG | Inter-Range Instrumentation Group |
| WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz | | WWVB | LF Radio WWVB Ft. Collins, CO 60 kHz |
| DCF | LF Radio DCF77 Mainflingen, DE 77.5 kHz | | DCF | LF Radio DCF77 Mainflingen, DE 77.5 kHz |
| HBG | LF Radio HBG Prangins, HB 75 kHz | | HBG | LF Radio HBG Prangins, HB 75 kHz |
| MSF | LF Radio MSF Anthorn, UK 60 kHz (Rugby until April 2007) | | MSF | LF Radio MSF Anthorn, UK 60 kHz |
| JJY | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz | | JJY | LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz |
| LORC | MF Radio LORAN C 100 kHz | | LORC | MF Radio LORAN C station, 100 kHz |
| TDF | MF Radio Allouis, FR 162 kHz | | TDF | MF Radio Allouis, FR 162 kHz |
| CHU | HF Radio CHU Ottawa, Ontario | | CHU | HF Radio CHU Ottawa, Ontario |
| WWV | HF Radio WWV Ft. Collins, CO | | WWV | HF Radio WWV Ft. Collins, CO |
| WWVH | HF Radio WWVH Kauai, HI | | WWVH | HF Radio WWVH Kauai, HI |
| NIST | NIST telephone modem | | NIST | NIST telephone modem |
| ACTS | NIST telephone modem | | ACTS | NIST telephone modem |
| USNO | USNO telephone modem | | USNO | USNO telephone modem |
| PTB | European telephone modem | | PTB | European telephone modem |
+------+----------------------------------------------------------+ +------+----------------------------------------------------------+
Figure 13: Reference Identifiers Figure 12: Reference Identifiers
Above stratum 1 (secondary servers and clients) this is the reference Above stratum 1 (secondary servers and clients) this is the reference
identifier of the server and is intended to detect timing loops. If identifier of the server and can be used to detect timing loops. If
using the IPv4 address family, the identifier is the four-octet IPv4 using the IPv4 address family, the identifier is the four-octet IPv4
address. If using the IPv6 address family, it is the first four address. If using the IPv6 address family, it is the first four
octets of the MD5 hash of the IPv6 address. Note that, when using octets of the MD5 hash of the IPv6 address. Note that, when using
the IPv6 address family on an NTPv4 server with a NTPv3 client, the the IPv6 address family on an NTPv4 server with a NTPv3 client, the
Reference Identifier field appears to be a random value and a timing Reference Identifier field appears to be a random value and a timing
loop might not be detected. loop might not be detected.
Reference Timestamp: Time when the system clock was last set or Reference Timestamp: Time when the system clock was last set or
corrected, in NTP timestamp format. corrected, in NTP timestamp format.
skipping to change at page 24, line 25 skipping to change at page 23, line 26
for the client, in NTP timestamp format. for the client, in NTP timestamp format.
Destination Timestamp (dst): Time at the client when the reply Destination Timestamp (dst): Time at the client when the reply
arrived from the server, in NTP timestamp format. arrived from the server, in NTP timestamp format.
Note: Destination Timestamp field is not included as a header field; Note: Destination Timestamp field is not included as a header field;
it is determined upon arrival of the packet and made available in the it is determined upon arrival of the packet and made available in the
packet buffer data structure. packet buffer data structure.
The MAC consists of the Key Identifier followed by the Message The MAC consists of the Key Identifier followed by the Message
Digest. The message digest, or cryptosum, is calculated as in [8] Digest. The message digest, or cryptosum, is calculated as in [16]
over all header and optional extension fields, but not the MAC over all NTP header and optional extension fields, but not the MAC
itself. itself.
Extension Field n: See Section 7.5 for a description of the format of
this field.
Key Identifier (keyid): 32-bit unsigned integer used by the client Key Identifier (keyid): 32-bit unsigned integer used by the client
and server to designate a secret 128-bit MD5 key. and server to designate a secret 128-bit MD5 key.
Message Digest (digest): 128-bit bitstring computed by the keyed MD5 Message Digest (digest): 128-bit bitstring computed by the keyed MD5
message digest computed over all the words in the header and message digest computed over all the words in the header and
extension fields, but not the MAC itself. extension fields, but not the MAC itself.
7.4. The Kiss-o'-Death Packet 7.4. The Kiss-o'-Death Packet
If the Stratum field is 0, which implies unspecified or invalid, the If the Stratum field is 0, which implies unspecified or invalid, the
Reference Identifier field can be used to convey messages useful for Reference Identifier field can be used to convey messages useful for
status reporting and access control. These are called Kiss-o'-Death status reporting and access control. These are called Kiss-o'-Death
(KoD) packets and the ASCII messages they convey are called kiss (KoD) packets and the ASCII messages they convey are called kiss
codes. The KoD packets got their name because an early use was to codes. The KoD packets got their name because an early use was to
tell clients to stop sending packets that violate server access tell clients to stop sending packets that violate server access
controls. The kiss codes can provide useful information for an controls. The kiss codes can provide useful information for an
intelligent client, either NTPv4 or SNTPv4. Kiss codes are encoded intelligent client, either NTPv4 or SNTPv4. Kiss codes are encoded
in four-character ASCII strings left justified and zero filled. The in four-character ASCII strings left justified and zero filled. The
strings are designed for character displays and log files. A list of strings are designed for character displays and log files. A list of
the currently-defined kiss codes is given in Figure 14. Other than the currently-defined kiss codes is given in Figure 13. Recipients
displaying the kiss code, KoD packets have no protocol significance of kiss codes MUST inspect them and in the following cases take these
and are discarded after inspection. actions:
a. For kiss codes: DENY, RSTR the client MUST demobilize any
associations to that server and stop sending packets to that
server;
b. For kiss code: RATE the client MUST immediately reduce its
polling interval to that server and continue to reduce it each
time it receives a RATE kiss code.
c. Other than the above conditions, KoD packets have no protocol
significance and are discarded after inspection.
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| Code | Meaning | | Code | Meaning |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server | | ACST | The association belongs to a unicast server |
| AUTH | Server authentication failed | | AUTH | Server authentication failed |
| AUTO | Autokey sequence failed | | AUTO | Autokey sequence failed |
| BCST | The association belongs to a broadcast server | | BCST | The association belongs to a broadcast server |
| CRYP | Cryptographic authentication or identification failed | | CRYP | Cryptographic authentication or identification failed |
| DENY | Access denied by remote server | | DENY | Access denied by remote server |
skipping to change at page 25, line 29 skipping to change at page 24, line 43
| NKEY | No key found. Either the key was never installed or is | | NKEY | No key found. Either the key was never installed or is |
| | not trusted | | | not trusted |
| RATE | Rate exceeded. The server has temporarily denied access | | RATE | Rate exceeded. The server has temporarily denied access |
| | because the client exceeded the rate threshold | | | because the client exceeded the rate threshold |
| RMOT | Alteration of association from a remote host running | | RMOT | Alteration of association from a remote host running |
| | ntpdc. | | | ntpdc. |
| STEP | A step change in system time has occurred, but the | | STEP | A step change in system time has occurred, but the |
| | association has not yet resynchronized | | | association has not yet resynchronized |
+------+------------------------------------------------------------+ +------+------------------------------------------------------------+
Figure 14: Kiss Codes Figure 13: Kiss Codes
7.5. NTP Extension Field Format 7.5. NTP Extension Field Format
In NTPv4 one or more extension fields can be inserted after the In NTPv4 one or more extension fields can be inserted after the
header and before the MAC, which is always present when an extension header and before the MAC, which is always present when an extension
field is present. Other than defining the field format, this field is present. Other than defining the field format, this
document makes no use of the field contents. An extension field document makes no use of the field contents. An extension field
contains a request or response message in the format shown in contains a request or response message in the format shown in
Figure 15. Figure 14.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Field Type | Length | | Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Filestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. Value . . Value .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Signature .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) | | Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Extension Field Format Figure 14: Extension Field Format
All extension fields are zero-padded to a word (4 octets) boundary. All extension fields are zero-padded to a word (4 octets) boundary.
The Field Type field is specific to the defined function and is not The Field Type field is specific to the defined function and is not
elaborated here. While the minimum field length containing required elaborated here. While the minimum field length containing required
fields is 4 words (16 octets), a maximum field length remains to be fields is 4 words (16 octets), a maximum field length remains to be
established. established.
The Length field is a 16-bit integer which indicates the length of The Length field is a 16-bit unsigned integer which indicates the
the entire extension field in octets, including the Padding field. length of the entire extension field in octets, including the Padding
field.
The 32-bit Association ID field is set by clients to the value
previously received from the server or 0 otherwise. The server sets
the Association ID field when sending a response as a handle for
subsequent exchanges.
The Timestamp and Filestamp 32-bit fields carry the seconds field of
an NTP timestamp. The Timestamp field establishes the signature
epoch of the data in the extension field, while the filestamp
establishes the generation epoch of the file that ultimately produced
the data.
The 32-bit Value Length field indicates the length of the Value field
in octets. The minimum length of this field is 0, in which case the
Value field itself is omitted.
The 32-bit Signature Length field indicates the length of the
Signature field in octets. The minimum length of this field is 0, in
which case the Signature field itself is omitted.
If both the Value Length and Signature Length fields are 0, both of
these words can be omitted, in which case the extension field has
length 4 words.
The presence of the MAC and extension fields in the packet is
determined from the length of the remaining area after the header to
the end of the packet. The parser initializes a pointer just after
the header. If the Length field is not a multiple of 4, a format
error has occurred and the packet is discarded. The following cases
are possible based on the remaining length in words.
0 The packet contains no MAC and is not authenticated.
1 The packet is an error report or crypto-NAK.
2, 3, 4 The packet is discarded with a format error.
5 The remainder of the packet is the 160-bit MAC.
>5 One or more extension fields are present.
If an extension field is present, the parser examines the Length
field. If the length is less than 4 or not a multiple of 4, a format
error has occurred and the packet is discarded; otherwise, the parser
increments the pointer by this value. The parser now uses the same
rules as above to determine whether a MAC is present and/or another
extension field. An additional implementation dependent test is
necessary to ensure the pointer does not stray outside the buffer
space occupied by the packet.
8. On Wire Protocol 8. On Wire Protocol
The heart of the NTP on-wire protocol is the core mechanism which The heart of the NTP on-wire protocol is the core mechanism which
exchanges time values between servers, peers and clients. It is exchanges time values between servers, peers and clients. It is
inherently resistant to lost or duplicate packets. Data integrity is inherently resistant to lost or duplicate packets. Data integrity is
provided by the IP and UDP checksums. No flow control or provided by the IP and UDP checksums. No flow control or
retransmission facilities are provided or necessary. The protocol retransmission facilities are provided or necessary. The protocol
uses timestamps, either extracted from packet headers or struck from uses timestamps, either extracted from packet headers or struck from
the system clock upon the arrival or departure of a packet. the system clock upon the arrival or departure of a packet.
Timestamps are precision data and should be restruck in case of link Timestamps are precision data and should be restruck in case of link
level retransmission and corrected for the time to compute a MAC on level retransmission and corrected for the time to compute a MAC on
transmit. transmit.
NTP messages make use of two different communication modes, one-to- NTP messages make use of two different communication modes, one-to-
one and one-to-many, commonly referred to as unicast and broadcast. one and one-to-many, commonly referred to as unicast and broadcast.
For the purposes of this document, the term broadcast is interpreted For the purposes of this document, the term broadcast is interpreted
to mean any available one-to-many mechanism. For IPv4 this equates as any available one-to-many mechanism. For IPv4 this equates to
to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to either IPv4 broadcast or IPv4 multicast. For IPv6 this equates to
IPv6 multicast. For this purpose, IANA has allocated the IPv4 IPv6 multicast. For this purpose, IANA has allocated the IPv4
multicast address 224.0.1.1 and the IPv6 multicast address ending multicast address 224.0.1.1 and the IPv6 multicast address ending
:101, with prefix determined by scoping rules. :101, with prefix determined by scoping rules.
The on-wire protocol uses four timestamps numbered T1 through T4 and The on-wire protocol uses four timestamps numbered t1 through t4 and
three state variables org, rec and xmt, as shown in Figure 17. This three state variables org, rec and xmt, as shown in Figure 15. This
figure shows the most general case where each of two peers, A and B, figure shows the most general case where each of two peers, A and B,
independently measure the offset and delay relative to the other. independently measure the offset and delay relative to the other.
For purposes of illustration the individual timestamp values are For purposes of illustration the packet timestamps are shown in lower
shown in lower case with a number indicating the order of case, while the state variables are shown in upper case. The state
transmission and reception. variables are copied from the packet timestamps upon arrival or
departure of a packet.
t2 t3 t6 t7 t2 t3 t6 t7
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
T1 | 0 | | t1 | | t3 | | t5 | | 0 | | t1 | | t3 | | t5 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
T2 | 0 | | t2 | | t4 | | t6 | Packet | 0 | | t2 | | t4 | | t6 | Packet
+---------+ +---------+ +---------+ +---------+ Variables +---------+ +---------+ +---------+ +---------+ Timestamps
T3 | t1 | |t3=clock | | t5 | |t7=clock | | t1 | |t3=clock | | t5 | |t7=clock |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
T4 |t2=clock | |t6=clock | |t2=clock | |t6=clock |
+---------+ +---------+ +---------+ +---------+
Peer B Peer B
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
org | t1 | | t1 | | T3<>t1? | | t5 | org | T1 | | T1 | | t5<>T1? | | T5 |
+---------+ +---------+ +---------+ +---------+ State +---------+ +---------+ +---------+ +---------+ State
rec | t2 | | t2 | | t6 | | t6 | Variables rec | T2 | | T2 | | T6 | | T6 | Variables
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
xmt | 0 | | t3 | | T1<>t3? | | t7 | xmt | 0 | | T3 | | t3=T3? | | T7 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
t2 t3 t6 t7 t2 t3 t6 t7
--------------------------------------------------------- ---------------------------------------------------------
/\ \ /\ \ /\ \ /\ \
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \/ / \/ / \/ / \/
--------------------------------------------------------- ---------------------------------------------------------
t1 t4 t5 t8 t1 t4 t5 t8
t1 t4 t5 t8 t1 t4 t5 t8
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
T1 | 0 | | t1 | | t3 | | t5 | | 0 | | t1 | | t3 | | t5 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
T2 | 0 | | t2 | | t4 | | t6 | Packet | 0 | | t2 | | t4 | | t6 | Packet
+---------+ +---------+ +---------+ +---------+ Variables +---------+ +---------+ +---------+ +---------+ Timestamps
T3 |t1=clock | | t3 | |t5=clock | | t7 | |t1=clock | | t3 | |t5=clock | | t7 |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
T4 |t4=clock | |t8=clock | |t4=clock | |t8=clock |
+---------+ +---------+ +---------+ +---------+
Peer A Peer A
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
org | 0 | | T3<>0? | | t3 | | T3<>t3? | org | 0 | | t3<>0? | | T3 | | t7<>T3? |
+---------+ +---------+ +---------+ +---------+ State +---------+ +---------+ +---------+ +---------+ State
rec | 0 | | t4 | | t4 | | t8 | Variables rec | 0 | | T4 | | T4 | | T8 | Variables
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
xmt | t1 | | T1=t1? | | t5 | | T1<>t5? | xmt | T1 | | t1=T1? | | T5 | | t5=T5? |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Figure 15: On-Wire Protocol
Figure 17: On-Wire Protocol
In the figure the first packet transmitted by A contains only the In the figure the first packet transmitted by A contains only the
transmit timestamp T3 with value t1. B receives the packet at t2 and origin timestamp t1, which is then copied to T1. B receives the
saves the origin timestamp T1 with value t1 in state variable org and packet at t2 and copies t1 to T1 and the receive timestamp t2 to T2.
the destination timestamp T4 with value t2 in state variable rec. At At this time or some time later at t3, B sends a packet to A
this time or some time later B sends a packet to A containing the org containing t1 and t2 and in addition the transmit timestamp t3. All
and rec state variables in T1 and T2, respectively and in addition three timestamps are copied to the corresponding state variables. A
the transmit timestamp T3 with value t3, which is saved in the xmt receives the packet at t4 containing the three timestamps t1, t2 and
state variable. When this packet arrives at A the packet header t3 and in addition the destination timestamp t4. These four
variables T1, T2, T3 and destination timestamp T4 represent the four timestamps are used to compute the offset and delay of B relative to
timestamps necessary to compute the offset and delay of B relative to
A, as described below. A, as described below.
Before the A state variables are updated, two sanity checks are Before the xmt and org state variables are updated, two sanity checks
performed in order to protect against duplicate or bogus packets. A are performed in order to protect against duplicate, bogus or
packet is a duplicate if the transmit timestamp T3 in the packet replayed packets. In the exchange above, a packet is duplicate or
matches the xmt state variable. A packet is bogus if the origin replay if the transmit timestamp t3 in the packet matches the org
timestamp T1 in the packet does not match the org state variable. In state variable T3. A packet is bogus if the origin timestamp t1 in
either of these cases the state variables are updated, then the the packet does not match the xmt state variable T1. In either of
packet is discarded. these cases the state variables are updated, then the packet is
discarded. To protect against replay of the last transmitted packet,
the xmt state variable is set to zero immediately after a successful
bogus check.
The four most recent timestamps, T1 through T4, are used to compute The four most recent timestamps, T1 through T4, are used to compute
the offset of B relative to A the offset of B relative to A
theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)] theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]
and the round trip delay and the round trip delay
delta = T(ABA) = (T4-T1) - (T3-T2). delta = T(ABA) = (T4-T1) - (T3-T2).
skipping to change at page 31, line 5 skipping to change at page 29, line 9
In implementations where floating double arithmetic is available, the In implementations where floating double arithmetic is available, the
first-order differences can be converted to floating double and the first-order differences can be converted to floating double and the
second-order sums and differences computed in that arithmetic. Since second-order sums and differences computed in that arithmetic. Since
the second-order terms are typically very small relative to the the second-order terms are typically very small relative to the
timestamp magnitudes, there is no loss in significance, yet the timestamp magnitudes, there is no loss in significance, yet the
unambiguous range is restored from 34 years to 68 years. unambiguous range is restored from 34 years to 68 years.
In some scenarios where the initial frequency offset of the client is In some scenarios where the initial frequency offset of the client is
relatively large and the actual propagation time small, it is relatively large and the actual propagation time small, it is
possible that the delay computation becomes negative. For instance, possible for the delay computation to becomes negative. For
if the frequency difference is 100 PPM and the interval T4-T1 is 64 instance, if the frequency difference is 100 PPM and the interval
s, the apparent delay is -6.4 ms. Since negative values are T4-T1 is 64 s, the apparent delay is -6.4 ms. Since negative values
misleading in subsequent computations, the value of delta should be are misleading in subsequent computations, the value of delta should
clamped not less than s.rho, where s.rho is the system precision be clamped not less than s.rho, where s.rho is the system precision
described in Section 11.1, expressed in seconds. described in Section 11.1, expressed in seconds.
The discussion above assumes the most general case where two The discussion above assumes the most general case where two
symmetric peers independently measure the offsets and delays between symmetric peers independently measure the offsets and delays between
them. In the case of a stateless server, the protocol can be them. In the case of a stateless server, the protocol can be
simplified. A stateless server copies T3 and T4 from the client simplified. A stateless server copies T3 and T4 from the client
packet to T1 and T2 of the server packet and tacks on the transmit packet to T1 and T2 of the server packet and tacks on the transmit
timestamp T3 before sending it to the client. Additional details for timestamp T3 before sending it to the client. Additional details for
filling in the remaining protocol fields are given in a Section 9 and filling in the remaining protocol fields are given in a Section 9 and
following sections and in the appendix. following sections and in the appendix.
skipping to change at page 31, line 49 skipping to change at page 30, line 7
The peer process is called upon arrival of a server or peer packet. The peer process is called upon arrival of a server or peer packet.
It runs the on-wire protocol to determine the clock offset and round It runs the on-wire protocol to determine the clock offset and round
trip delay and in addition computes statistics used by the system and trip delay and in addition computes statistics used by the system and
poll processes. Peer variables are instantiated in the association poll processes. Peer variables are instantiated in the association
data structure when the structure is initialized and updated by data structure when the structure is initialized and updated by
arriving packets. There is a peer process, poll process and arriving packets. There is a peer process, poll process and
association for each server. association for each server.
9.1. Peer Process Variables 9.1. Peer Process Variables
Figure 18, Figure 19, Figure 20 and Figure 21 summarize the common Figure 16, Figure 17, Figure 18 and Figure 19 summarize the common
names, formula names and a short description of the peer variables. names, formula names and a short description of the peer variables.
The common names and formula names are interchangeable; formula names The common names and formula names are interchangeable; formula names
are intended for equations where space is important. Unless noted are intended to increase readability of equations in this
otherwise, all peer variables have assumed prefix p. specification. Unless noted otherwise, all peer variables have
assumed prefix p.
+---------+----------+-----------------------+ +---------+----------+-----------------------+
| Name | Formula | Description | | Name | Formula | Description |
+---------+----------+-----------------------+ +---------+----------+-----------------------+
| srcaddr | srcaddr | source address | | srcaddr | srcaddr | source address |
| srcport | srcport | source port | | srcport | srcport | source port |
| dstaddr | dstaddr | destination address | | dstaddr | dstaddr | destination address |
| dstport | destport | destination port | | dstport | destport | destination port |
| keyid | keyid | key identifier key ID | | keyid | keyid | key identifier key ID |
+---------+----------+-----------------------+ +---------+----------+-----------------------+
Figure 18: Peer Process Configuration Variables Figure 16: Peer Process Configuration Variables
+-----------+------------+---------------------+ +-----------+------------+---------------------+
| Name | Formula | Description | | Name | Formula | Description |
+-----------+------------+---------------------+ +-----------+------------+---------------------+
| leap | leap | leap indicator | | leap | leap | leap indicator |
| version | version | version number | | version | version | version number |
| mode | mode | mode | | mode | mode | mode |
| stratum | stratum | stratum | | stratum | stratum | stratum |
| ppoll | ppoll | peer poll exponent | | ppoll | ppoll | peer poll exponent |
| rootdelay | delta_r | root delay | | rootdelay | delta_r | root delay |
| rootdisp | epsilon_r | root dispersion | | rootdisp | epsilon_r | root dispersion |
| refid | refid | reference ID | | refid | refid | reference ID |
| reftime | reftime | reference timestamp | | reftime | reftime | reference timestamp |
+-----------+------------+---------------------+ +-----------+------------+---------------------+
Figure 19: Peer Process Packet Variables Figure 17: Peer Process Packet Variables
+------+---------+--------------------+ +------+---------+--------------------+
| Name | Formula | Description | | Name | Formula | Description |
+------+---------+--------------------+ +------+---------+--------------------+
| org | T1 | origin timestamp | | org | T1 | origin timestamp |
| rec | T2 | receive timestamp | | rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp | | xmt | T3 | transmit timestamp |
| t | t | packet time | | t | t | packet time |
+------+---------+--------------------+ +------+---------+--------------------+
Figure 18: Peer Process Timestamp Variables
Figure 20: Peer Process Timestamp Variables
+--------+---------+-----------------+ +--------+---------+-----------------+
| Name | Formula | Description | | Name | Formula | Description |
+--------+---------+-----------------+ +--------+---------+-----------------+
| offset | theta | clock offset | | offset | theta | clock offset |
| delay | delta | roundtrip delay | | delay | delta | roundtrip delay |
| disp | epsilon | dispersion | | disp | epsilon | dispersion |
| jitter | psi | jitter | | jitter | psi | jitter |
| filter | filter | clock filter | | filter | filter | clock filter |
| tp | t_p | filter time | | tp | t_p | filter time |
+--------+---------+-----------------+ +--------+---------+-----------------+
Figure 21: Peer Process Statistics Variables Figure 19: Peer Process Statistics Variables
The following configuration variables are normally initialized when The following configuration variables are normally initialized when
the association is mobilized, either from a configuration file or the association is mobilized, either from a configuration file or
upon the arrival of the first packet for an unknown association. upon the arrival of the first packet for an unknown association.
srcaddr: IP address of the remote server or reference clock. This srcaddr: IP address of the remote server or reference clock. This
becomes the destination IP address in packets sent from this becomes the destination IP address in packets sent from this
association. association.
srcport: UDP port number of the server or reference clock. This srcport: UDP port number of the server or reference clock. This
skipping to change at page 33, line 42 skipping to change at page 31, line 44
address in packets sent from this association. address in packets sent from this association.
dstport: UDP port number of the client, ordinarily the NTP port dstport: UDP port number of the client, ordinarily the NTP port
number PORT (123) assigned by the IANA. This becomes the source port number PORT (123) assigned by the IANA. This becomes the source port
number in packets sent from this association. number in packets sent from this association.
keyid: Symmetric key ID for the 128-bit MD5 key used to generate and keyid: Symmetric key ID for the 128-bit MD5 key used to generate and
verify the MAC. The client and server or peer can use different verify the MAC. The client and server or peer can use different
values, but they must map to the same key. values, but they must map to the same key.
The variables defined in Figure 19 are updated from the packet header The variables defined in Figure 17 are updated from the packet header
as each packet arrives. They are interpreted in the same way as the as each packet arrives. They are interpreted in the same way as the
packet variables of the same names. It is convenient for later packet variables of the same names. It is convenient for later
processing to convert the NTP short format packet values r.rootdelay processing to convert the NTP short format packet values r.rootdelay
and r.rootdisp to floating doubles as peer variables. and r.rootdisp to floating doubles as peer variables.
The variables defined in Figure 20 include the timestamps exchanged The variables defined in Figure 18 include the timestamps exchanged
by the on-wire protocol in Section 8. The t variable is the seconds by the on-wire protocol in Section 8. The t variable is the seconds
counter c.t associated with these values. The c.t variable is counter c.t associated with these values. The c.t variable is
maintained by the clock adjust process described in Section 12. It maintained by the clock adjust process described in Section 12. It
counts the seconds since the service was started. The variables counts the seconds since the service was started. The variables
defined in Figure 21 include the statistics computed by the defined in Figure 19 include the statistics computed by the
clock_filter() routine described in Section 10. The tp variable is clock_filter() routine described in Section 10. The tp variable is
the seconds counter associated with these values. the seconds counter associated with these values.
9.2. Peer Process Operations 9.2. Peer Process Operations
The receive() routine in Appendix A.5.1 shows the peer process code The receive() routine in Appendix A.5.1 shows the peer process code
flow upon the arrival of a packet. The access() routine in flow upon the arrival of a packet. The access() routine in
Appendix A.5.4 implements access restrictions using an access control Appendix A.5.4 implements access restrictions using an access control
list (ACL). There is no specific method required for access control, list (ACL). There is no specific method required for access control,
although it is recommended that implementations include such a although it is recommended that implementations include such a
scheme, which is similar to many others now in widespread use. scheme, which is similar to many others now in widespread use.
Format checks require correct field length and alignment, acceptable Format checks require correct field length and alignment, acceptable
version number (1-4) and correct extension field syntax, if present. version number (1-4) and correct extension field syntax, if present.
There is no specific requirement for authentication; however, if There is no specific requirement for authentication; however, if
authentication is implemented, the symmetric key scheme described in authentication is implemented, the symmetric key scheme described in
Appendix A.2 must be among the supported schemes. This scheme uses Appendix A.2 must be among the supported schemes. This scheme uses
the MD5 keyed hash algorithm described in [8]. the MD5 keyed hash algorithm described in [16].
Next, the association table is searched for matching source address Next, the association table is searched for matching source address
and source port using the find_assoc() routine in Appendix A.5.1. and source port using the find_assoc() routine in Appendix A.5.1.
Figure 22 is a dispatch table where the columns correspond to the Figure 20 is a dispatch table where the columns correspond to the
packet mode and rows correspond to the association mode. The packet mode and rows correspond to the association mode. The
intersection of the association and packet modes dispatches intersection of the association and packet modes dispatches
processing to one of the following steps. processing to one of the following steps.
+------------------+---------------------------------------+ +------------------+---------------------------------------+
| | Packet Mode | | | Packet Mode |
+------------------+-------+-------+-------+-------+-------+ +------------------+-------+-------+-------+-------+-------+
| Association Mode | 1 | 2 | 3 | 4 | 5 | | Association Mode | 1 | 2 | 3 | 4 | 5 |
+------------------+-------+-------+-------+-------+-------+ +------------------+-------+-------+-------+-------+-------+
| No Association 0 | NEWPS | DSCRD | FXMIT | MANY | NEWBC | | No Association 0 | NEWPS | DSCRD | FXMIT | MANY | NEWBC |
| Symm. Active 1 | PROC | PROC | DSCRD | DSCRD | DSCRD | | Symm. Active 1 | PROC | PROC | DSCRD | DSCRD | DSCRD |
| Symm. Passive 2 | PROC | ERR | DSCRD | DSCRD | DSCRD | | Symm. Passive 2 | PROC | ERR | DSCRD | DSCRD | DSCRD |
| Client 3 | DSCRD | DSCRD | DSCRD | PROC | DSCRD | | Client 3 | DSCRD | DSCRD | DSCRD | PROC | DSCRD |
| Server 4 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD | | Server 4 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD |
| Broadcast 5 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD | | Broadcast 5 | DSCRD | DSCRD | DSCRD | DSCRD | DSCRD |
| Bcast Client 6 | DSCRD | DSCRD | DSCRD | DSCRD | PROC | | Bcast Client 6 | DSCRD | DSCRD | DSCRD | DSCRD | PROC |
+------------------+-------+-------+-------+-------+-------+ +------------------+-------+-------+-------+-------+-------+
Figure 22: Peer Dispatch Table Figure 20: Peer Dispatch Table
DSCRD. This is a nonfatal violation of protocol as the result of a DSCRD. This indicates a nonfatal violation of protocol as the result
programming error, long delayed packet or replayed packet. The peer of a programming error, long delayed packet or replayed packet. The
process discards the packet and exits. peer process discards the packet and exits.
ERR. This is a fatal violation of protocol as the result of a ERR. This indicates a fatal violation of protocol as the result of a
programming error, long delayed packet or replayed packet. The peer programming error, long delayed packet or replayed packet. The peer
process discards the packet, demobilizes the symmetric passive process discards the packet, demobilizes the symmetric passive
association and exits. association and exits.
FXMIT. This is a client (mode 3) packet matching no association FXMIT. This indicates a client (mode 3) packet matching no
(mode 0). If the destination address is not a broadcast address, the association (mode 0). If the destination address is not a broadcast
server constructs a server (mode 4) packet and returns it to the address, the server constructs a server (mode 4) packet and returns
client without retaining state. The server packet header is it to the client without retaining state. The server packet header
constructed by the fast_xmit() routine in Appendix A.5.3. The packet is constructed by the fast_xmit() routine in Appendix A.5.3. The
header is assembled from the receive packet and system variables as packet header is assembled from the receive packet and system
shown in Figure 23. If the s.rootdelay and s.rootdisp system variables as shown in Figure 21. If the s.rootdelay and s.rootdisp
variables are stored in floating double, they must be converted to system variables are stored in floating double, they must be
NTP short format first. converted to NTP short format first.
+-----------------------------------+ +-----------------------------------+
| Packet Variable --> Variable | | Packet Variable --> Variable |
+-----------------------------------+ +-----------------------------------+
| r.leap --> p.leap | | r.leap --> p.leap |
| r.mode --> p.mode | | r.mode --> p.mode |
| r.stratum --> p.stratum | | r.stratum --> p.stratum |
| r.poll --> p.ppoll | | r.poll --> p.ppoll |
| r.rootdelay --> p.rootdelay | | r.rootdelay --> p.rootdelay |
| r.rootdisp --> p.rootdisp | | r.rootdisp --> p.rootdisp |
| r.refid --> p.refid | | r.refid --> p.refid |
| r.reftime --> p.reftime | | r.reftime --> p.reftime |
| r.keyid --> p.keyid | | r.keyid --> p.keyid |
+-----------------------------------+ +-----------------------------------+
Figure 23: Receive Packet Header Figure 21: Receive Packet Header
Note that, if authentication fails, the server returns a special Note that, if authentication fails, the server returns a special
message called a crypto-NAK. This message includes the normal NTP message called a crypto-NAK. This message includes the normal NTP
header data shown in Figure 9, but with a MAC consisting of four header data shown in Figure 8, but with a MAC consisting of four
octets of zeros. The client MAY accept or reject the data in the octets of zeros. The client MAY accept or reject the data in the
message. After these actions the peer process exits. message. After these actions the peer process exits.
If the destination address is a multicast address, the sender is If the destination address is a multicast address, the sender is
operating in manycast client mode. If the packet is valid and the operating in manycast client mode. If the packet is valid and the
server stratum is less than the client stratum, the server sends an server stratum is less than the client stratum, the server sends an
ordinary server (mode 4) packet, but using its unicast destination ordinary server (mode 4) packet, but using its unicast destination
address. A crypto-NAK is not sent if authentication fails. After address. A crypto-NAK is not sent if authentication fails. After
these actions the peer process exits. these actions the peer process exits.
MANY: This is a server (mode 4) packet matching no association. MANY: This indicates a server (mode 4) packet matching no
Ordinarily, this can happen only as the result of a manycast server association. Ordinarily, this can happen only as the result of a
reply to a previously sent multicast client packet. If the packet is manycast server reply to a previously sent multicast client packet.
valid, an ordinary client (mode 3) association is mobilized and If the packet is valid, an ordinary client (mode 3) association is
operation continues as if the association was mobilized by the mobilized and operation continues as if the association was mobilized
configuration file. by the configuration file.
NEWBC. This is a broadcast (mode 5) packet matching no association. NEWBC. This indicates a broadcast (mode 5) packet matching no
The client mobilizes either a client (mode 3) or broadcast client association. The client mobilizes either a client (mode 3) or
(mode 6) association as shown in the mobilize() and clear() routines broadcast client (mode 6) association as shown in the mobilize() and
in Appendix A.2. Then the packet() routine in Appendix A.5.1.1 clear() routines in Appendix A.2. Then the packet() routine in
validates the packet and initializes the peer variables. Appendix A.5.1.1 validates the packet and initializes the peer
variables.
If the implementation supports no additional security or calibration If the implementation supports no additional security or calibration
functions, the association mode is set to broadcast client (mode 6) functions, the association mode is set to broadcast client (mode 6)
and the peer process exits. Implementations supporting public key and the peer process exits. Implementations supporting public key
authentication MAY run the Autokey or equivalent security protocol. authentication MAY run the Autokey or equivalent security protocol.
Implementations SHOULD set the association mode to 3 and run a short Implementations SHOULD set the association mode to 3 and run a short
client/server exchange to determine the propagation delay. Following client/server exchange to determine the propagation delay. Following
the exchange the association mode is set to 6 and the peer process the exchange the association mode is set to 6 and the peer process
continues in listen-only mode. Note the distinction between a mode-6 continues in listen-only mode. Note the distinction between a mode-6
packet, which is reserved for the NTP monitor and control functions, packet, which is reserved for the NTP monitor and control functions,
and a mode-6 association. and a mode-6 association.
NEWPS. This is a symmetric active (mode 1) packet matching no NEWPS. This indicates a symmetric active (mode 1) packet matching no
association. The client mobilizes a symmetric passive (mode 2) association. The client mobilizes a symmetric passive (mode 2)
association as shown in the mobilize() routine and clear() routines association as shown in the mobilize() routine and clear() routines
in Appendix A.2. Processing continues in the PROC section below. in Appendix A.2. Processing continues in the PROC section below.
PROC. The packet matches an existing association. The packet PROC. This indicates a packet matching an existing association. The
timestamps are carefully checked to avoid invalid, duplicate or bogus packet timestamps are carefully checked to avoid invalid, duplicate
packets. Additional checks are summarized in Figure 24. Note that or bogus packets. Additional checks are summarized in Figure 22.
all packets, including a crypto-NAK, are considered valid only if Note that all packets, including a crypto-NAK, are considered valid
they survive these tests. only if they survive these tests.
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
| Packet Type | Description | | Packet Type | Description |
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
| 1 duplicate packet | The packet is at best an old duplicate | | 1 duplicate packet | The packet is at best an old duplicate |
| | or at worst a replay by a hacker. | | | or at worst a replay by a hacker. |
| | This can happen in symmetric modes if | | | This can happen in symmetric modes if |
| | the poll intervals are uneven. | | | the poll intervals are uneven. |
| 2 bogus packet | | | 2 bogus packet | |
| 3 invalid | One or more timestamp fields are | | 3 invalid | One or more timestamp fields are |
| | invalid. This normally happens in | | | invalid. This normally happens in |
| | symmetric modes when one peer sends | | | symmetric modes when one peer sends |
| | the first packet to the other and | | | the first packet to the other and |
| | before the other has received its | | | before the other has received its |
| | first reply. | | | first reply. |
| 4 access denied | The access controls have black | | 4 access denied | The access controls have blacklisted |
| | the source. |
| 5 authentication failure | The cryptographic message digest does | | 5 authentication failure | The cryptographic message digest does |
| | not match the MAC. | | | not match the MAC. |
| 6 unsynchronized | The server is not synchronized to a | | 6 unsynchronized | The server is not synchronized to a |
| | valid source. | | | valid source. |
| 7 bad header data | One or more header fields are invalid. | | 7 bad header data | One or more header fields are invalid. |
+--------------------------+----------------------------------------+ +--------------------------+----------------------------------------+
Figure 24: Packet Error Checks Figure 22: Packet Error Checks
Processing continues in the packet() routine in Appendix A.5.1.1. It Processing continues in the packet() routine in Appendix A.5.1.1. It
copies the packet variables to the peer variables as shown in copies the packet variables to the peer variables as shown in
Figure 23 and the packet() routine in Appendix A.5.2". The receive() Figure 21 and the packet() routine in Appendix A.5.2. The receive()
routine implements tests 1-5 in Figure 24; the packet() routine routine implements tests 1-5 in Figure 22; the packet() routine
implements tests 6-7. If errors are found the packet is discarded implements tests 6-7. If errors are found the packet is discarded
and the peer process exits. and the peer process exits.
The on-wire protocol calculates the clock offset theta and round trip The on-wire protocol calculates the clock offset theta and round trip
delay delta from the four most recent timestamps as described in delay delta from the four most recent timestamps as described in
Section 8. While it is in principle possible to do all calculations Section 8. While it is in principle possible to do all calculations
except the first-order timestamp differences in fixed-point except the first-order timestamp differences in fixed-point
arithmetic, it is much easier to convert the first-order differences arithmetic, it is much easier to convert the first-order differences
to floating doubles and do the remaining calculations in that to floating doubles and do the remaining calculations in that
arithmetic, and this will be assumed in the following description. arithmetic, and this will be assumed in the following description.
skipping to change at page 38, line 7 skipping to change at page 36, line 8
and the data are fresh. The register is shifted left by one bit when and the data are fresh. The register is shifted left by one bit when
a packet is sent and the rightmost bit is set to zero. As valid a packet is sent and the rightmost bit is set to zero. As valid
packets arrive, the packet() routine sets the rightmost bit to one. packets arrive, the packet() routine sets the rightmost bit to one.
If the register contains any nonzero bits, the server is considered If the register contains any nonzero bits, the server is considered
reachable; otherwise, it is unreachable. Since the peer poll reachable; otherwise, it is unreachable. Since the peer poll
interval might have changed since the last packet, the poll_update() interval might have changed since the last packet, the poll_update()
routine in Appendix A.5.7.2 is called to redetermine the host poll routine in Appendix A.5.7.2 is called to redetermine the host poll
interval. interval.
The dispersion statistic epsilon(t) represents the maximum error due The dispersion statistic epsilon(t) represents the maximum error due
to the frequency tolerance and time since the last packet was sent It to the frequency tolerance and time since the last packet was sent.
is initialized It is initialized
epsilon(t_0) = r.rho + s.rho + PHI * (T4-T1) epsilon(t_0) = r.rho + s.rho + PHI * (T4-T1)
when the measurement is made at t_0 according to the seconds counter. when the measurement is made at t_0 according to the seconds counter.
Here r.rho is the packet precision described in Section 7.3 and s.rho Here r.rho is the packet precision described in Section 7.3 and s.rho
is the system precision described in Section 11.1, both expressed in is the system precision described in Section 11.1, both expressed in
seconds. These terms are necessary to account for the uncertainty in seconds. These terms are necessary to account for the uncertainty in
reading the system clock in both the server and the client. reading the system clock in both the server and the client.
The dispersion then grows at constant rate PHI; in other words, at The dispersion then grows at constant rate PHI; in other words, at
time t, epsilon(t) = epsilon(t_0) + PHI * (t-t_0). With the default time t, epsilon(t) = epsilon(t_0) + PHI * (t-t_0). With the default
value PHI = 15 PPM, this amounts to about 1.3 s per day. With this value PHI = 15 PPM, this amounts to about 1.3 s per day. With this
understanding, the argument t will be dropped and the dispersion understanding, the argument t will be dropped and the dispersion
represented simply as epsilon. The remaining statistics are computed represented simply as epsilon. The remaining statistics are computed
by the clock filter algorithm described in the next section. by the clock filter algorithm described in the next section.
10. Clock Filter Algorithm 10. Clock Filter Algorithm
The clock filter algorithm, part of the peer process, is implemented The clock filter algorithm, part of the peer process, is implemented
in the clock_filter() routine in Appendix A.5.2. It grooms the in the clock_filter() routine of Appendix A.5.2. It grooms the
stream of on-wire data to select the samples most likely to represent stream of on-wire data to select the samples most likely to represent
accurate time. The algorithm produces the variables shown in accurate time. The algorithm produces the variables shown in
Figure 21, including the offset (theta), delay (delta), dispersion Figure 19, including the offset (theta), delay (delta), dispersion
(epsilon), jitter (psi) and time of arrival (t). These data are used (epsilon), jitter (psi) and time of arrival (t). These data are used
by the mitigation algorithms to determine the best and final offset by the mitigation algorithms to determine the best and final offset
used to discipline the system clock. They are also used to determine used to discipline the system clock. They are also used to determine
the server health and whether it is suitable for synchronization. the server health and whether it is suitable for synchronization.
The clock filter algorithm saves the most recent sample tuples The clock filter algorithm saves the most recent sample tuples
(theta, delta, epsilon, t) in the filter structure, which functions (theta, delta, epsilon, t) in the filter structure, which functions
as an 8-stage shift register. The tuples are saved in the order that as an 8-stage shift register. The tuples are saved in the order that
packets arrive. Here t is the packet time of arrival according to packets arrive. Here t is the packet time of arrival according to
the seconds counter and should not be confused with the peer variable the seconds counter and should not be confused with the peer variable
skipping to change at page 40, line 47 skipping to change at page 38, line 48
the system clock to the correct time. the system clock to the correct time.
The cluster algorithm selects one of the survivors as the system The cluster algorithm selects one of the survivors as the system
peer. The associated statistics (theta, delta, epsilon, jitter, t) peer. The associated statistics (theta, delta, epsilon, jitter, t)
are used to construct the system variables inherited by dependent are used to construct the system variables inherited by dependent
servers and clients and made available to other applications running servers and clients and made available to other applications running
on the same machine. on the same machine.
11.1. System Process Variables 11.1. System Process Variables
Figure 27 summarizes the common names, formula names and a short Figure 25 summarizes the common names, formula names and a short
description of each system variable. Unless noted otherwise, all description of each system variable. Unless noted otherwise, all
variables have assumed prefix s. variables have assumed prefix s.
+-----------+------------+------------------------+ +-----------+------------+------------------------+
| Name | Formula | Description | | Name | Formula | Description |
+-----------+------------+------------------------+ +-----------+------------+------------------------+
| t | t | update time | | t | t | update time |
| p | p | system peer identifier | | p | p | system peer identifier |
| leap | leap | leap indicator | | leap | leap | leap indicator |
| stratum | stratum | stratum | | stratum | stratum | stratum |
skipping to change at page 41, line 24 skipping to change at page 39, line 24
| jitter | PSI | combined jitter | | jitter | PSI | combined jitter |
| rootdelay | DELTA | root delay | | rootdelay | DELTA | root delay |
| rootdisp | EPSILON | root dispersion | | rootdisp | EPSILON | root dispersion |
| v | v | survivor list | | v | v | survivor list |
| refid | refid | reference ID | | refid | refid | reference ID |
| reftime | reftime | reference time | | reftime | reftime | reference time |
| NMIN | 3 | minimum survivors | | NMIN | 3 | minimum survivors |
| CMIN | 1 | minimum candidates | | CMIN | 1 | minimum candidates |
+-----------+------------+------------------------+ +-----------+------------+------------------------+
Figure 27: System Process Variables Figure 25: System Process Variables
Except for the t, p, offset and jitter variables and the NMIN and Except for the t, p, offset and jitter variables and the NMIN and
CMIN constants, the variables have the same format and interpretation CMIN constants, the variables have the same format and interpretation
as the peer variables of the same name. The NMIN and CMIN parameters as the peer variables of the same name. The NMIN and CMIN parameters
are used by the selection and cluster algorithms described in the are used by the selection and cluster algorithms described in the
next section. next section.
The t variable is the seconds counter at the last update determined The t variable is the seconds counter at the last update determined
by the clock_update() routine in Appendix A.5.5.4. The p variable is by the clock_update() routine in Appendix A.5.5.4. The p variable is
the system peer identifier determined by the cluster() routine in the system peer identifier determined by the cluster() routine in
skipping to change at page 41, line 51 skipping to change at page 39, line 51
The offset and jitter variables are determined by the combine() The offset and jitter variables are determined by the combine()
routine in Section 11.2.3. These values represent the best and final routine in Section 11.2.3. These values represent the best and final
offset and jitter used to discipline the system clock. Initially, offset and jitter used to discipline the system clock. Initially,
all variables are cleared to zero, then the leap is set to 3 all variables are cleared to zero, then the leap is set to 3
(unsynchronized) and stratum is set to MAXSTRAT (16). Remember that (unsynchronized) and stratum is set to MAXSTRAT (16). Remember that
MAXSTRAT is mapped to zero in the transmitted packet. MAXSTRAT is mapped to zero in the transmitted packet.
11.2. System Process Operations 11.2. System Process Operations
Figure 28 summarizes the system process operations performed by the Figure 26 summarizes the system process operations performed by the
clock_select() routine. The selection algorithm described in clock_select() routine. The selection algorithm described in
Section 11.2.1 produces a majority clique of presumed correct Section 11.2.1 produces a majority clique of presumed correct
candidates (truechimers) based on agreement principles. The cluster candidates (truechimers) based on agreement principles. The cluster
algorithm described in Section 11.2.2 discards outlyers to produce algorithm described in Section 11.2.2 discards outlyers to produce
the most accurate survivors. The combine algorithm described in the most accurate survivors. The combine algorithm described in
Section 11.2.3 provides the best and final offset for the clock Section 11.2.3 provides the best and final offset for the clock
discipline algorithm described in Appendix A.5.5.6. If the selection discipline algorithm described in Appendix A.5.5.6. If the selection
algorithm cannot produce a majority clique, or if it cannot produce algorithm cannot produce a majority clique, or if it cannot produce
at least CMIN survivors, the system process exits without at least CMIN survivors, the system process exits without
disciplining the system clock. If successful, the cluster algorithm disciplining the system clock. If successful, the cluster algorithm
skipping to change at page 43, line 47 skipping to change at page 41, line 47
+-----------------+ V no +-----------------+ V no
| s.p = NULL | +-------------------+ | s.p = NULL | +-------------------+
+-----------------+ | s.p = v_0.p | +-----------------+ | s.p = v_0.p |
| +-------------------+ | +-------------------+
V | V |
+-----------------+ V +-----------------+ V
| return (UNSYNC) | +-------------------+ | return (UNSYNC) | +-------------------+
+-----------------+ | return (SYNC) | +-----------------+ | return (SYNC) |
+-------------------+ +-------------------+
Figure 28: clock_select() Routine Figure 26: clock_select() Routine
11.2.1. Selection Algorithm 11.2.1. Selection Algorithm
Note that the selection and cluster algorithms are described Note that the selection and cluster algorithms are described
separately, but combined in the code skeleton. The selection separately, but combined in the code skeleton. The selection
algorithm operates to find an intersection interval containing a algorithm operates to find an intersection interval containing a
majority clique of truechimers using Byzantine agreement principles majority clique of truechimers using Byzantine agreement principles
originally proposed by Marzullo [9], but modified to improve originally proposed by Marzullo [8], but modified to improve
accuracy. An overview of the algorithm is given below and in the accuracy. An overview of the algorithm is given below and in the
first half of the clock_select() routine in Appendix A.5.5.1. first half of the clock_select() routine in Appendix A.5.5.1.
First, those servers which are unusable according to the rules of the First, those servers which are unusable according to the rules of the
protocol are detected and discarded by the accept() routine in protocol are detected and discarded by the accept() routine in
Appendix A.5.5.3. Next, a set of tuples (p, type, edge) is generated Appendix A.5.5.3. Next, a set of tuples (p, type, edge) is generated
for the remaining candidates. Here, p is the association identifier for the remaining candidates. Here, p is the association identifier
and type identifies the upper (+1), middle (0) and lower (-1) and type identifies the upper (+1), middle (0) and lower (-1)
endpoints of a correctness interval centered on theta for that endpoints of a correctness interval centered on theta for that
candidate. This results in three tuples, lowpoint (p, -1, theta - candidate. This results in three tuples, lowpoint (p, -1, theta -
skipping to change at page 47, line 13 skipping to change at page 45, line 13
the offset is greater than the panic threshold PANICT (1000 s) and the offset is greater than the panic threshold PANICT (1000 s) and
SHOULD cause the program to exit with a diagnostic message to the SHOULD cause the program to exit with a diagnostic message to the
system log. STEP means the offset is less than the panic threshold, system log. STEP means the offset is less than the panic threshold,
but greater than the step threshold STEPT (125 ms). In this case the but greater than the step threshold STEPT (125 ms). In this case the
clock is stepped to the correct offset, but since this means all peer clock is stepped to the correct offset, but since this means all peer
data have been invalidated, all associations MUST be reset and the data have been invalidated, all associations MUST be reset and the
client begins as at initial start. client begins as at initial start.
ADJ means the offset is less than the step threshold and thus a valid ADJ means the offset is less than the step threshold and thus a valid
update. In this case the system variables are updated from the peer update. In this case the system variables are updated from the peer
variables as shown in Figure 30. variables as shown in Figure 28.
+-------------------------------------------+ +-------------------------------------------+
| System Variable <-- System Peer Variable | | | System Variable <-- System Peer Variable | |
+-------------------------------------------+ +-------------------------------------------+
| s.leap <-- p.leap | | s.leap <-- p.leap |
| s.stratum <-- p.stratum + 1 | | s.stratum <-- p.stratum + 1 |
| s.offset <-- THETA | | s.offset <-- THETA |
| s.jitter <-- PSI | | s.jitter <-- PSI |
| s.rootdelay <-- p.delta_r + delta | | s.rootdelay <-- p.delta_r + delta |
| s.rootdisp <-- p.epsilon_r + p.epsilon + | | s.rootdisp <-- p.epsilon_r + p.epsilon + |
| p.psi + PHI * (s.t - p.t) | | p.psi + PHI * (s.t - p.t) |
| + |THETA| | | + |THETA| |
| s.refid <-- p.refid | | s.refid <-- p.refid |
| s.reftime <-- p.reftime | | s.reftime <-- p.reftime |
| s.t <-- p.t | | s.t <-- p.t |
+-------------------------------------------+ +-------------------------------------------+
Figure 30: System Variables Update Figure 28: System Variables Update
There is an important detail not shown. The dispersion increment There is an important detail not shown. The dispersion increment
(p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from (p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from
below by MINDISP. In subnets with very fast processors and networks below by MINDISP. In subnets with very fast processors and networks
and very small delay and dispersion this forces a monotone-definite and very small delay and dispersion this forces a monotone-definite
increase in s.rootdisp (EPSILON), which avoids loops between peers increase in s.rootdisp (EPSILON), which avoids loops between peers
operating at the same stratum. operating at the same stratum.
The system variables are available to dependent application programs The system variables are available to dependent application programs
as nominal performance statistics. The system offset THETA is the as nominal performance statistics. The system offset THETA is the
skipping to change at page 48, line 24 skipping to change at page 46, line 24
error. In a frequency-locked loop (FLL) design, periodic frequency error. In a frequency-locked loop (FLL) design, periodic frequency
updates at intervals mu are used directly to minimize the frequency updates at intervals mu are used directly to minimize the frequency
error and indirectly the time error. As shown in [5], a PLL usually error and indirectly the time error. As shown in [5], a PLL usually
works better when network jitter dominates, while a FLL works better works better when network jitter dominates, while a FLL works better
when oscillator wander dominates. This section contains an outline when oscillator wander dominates. This section contains an outline
of how the NTPv4 design works. An in-depth discussion of the design of how the NTPv4 design works. An in-depth discussion of the design
principles is provided in [5], which also includes a performance principles is provided in [5], which also includes a performance
analysis. analysis.
The discipline is implemented as the feedback control system shown in The discipline is implemented as the feedback control system shown in
Figure 31. The variable theta_r represents the combine algorithm Figure 29. The variable theta_r represents the combine algorithm
offset (reference phase) and theta_c the VFO offset (control phase). offset (reference phase) and theta_c the VFO offset (control phase).
Each update produces a signal V_d representing the instantaneous Each update produces a signal V_d representing the instantaneous
phase difference theta_r - theta_c. The clock filter for each server phase difference theta_r - theta_c. The clock filter for each server
functions as a tapped delay line, with the output taken at the tap functions as a tapped delay line, with the output taken at the tap
selected by the clock filter algorithm. The selection, cluster and selected by the clock filter algorithm. The selection, cluster and
combine algorithms combine the data from multiple filters to produce combine algorithms combine the data from multiple filters to produce
the signal V_s. The loop filter, with impulse response F(t), the signal V_s. The loop filter, with impulse response F(t),
produces the signal V_c which controls the VFO frequency omega_c and produces the signal V_c which controls the VFO frequency omega_c and
thus the integral of the phase theta_c which closes the loop. The thus the integral of the phase theta_c which closes the loop. The
V_c signal is generated by the clock adjust process in Section 12. V_c signal is generated by the clock adjust process in Section 12.
skipping to change at page 49, line 25 skipping to change at page 47, line 25
----- ....................................... | ----- ....................................... |
^ . Loop Filter . | ^ . Loop Filter . |
| . +---------+ x +-------------+ . | | . +---------+ x +-------------+ . |
| V_c . | |<-----| | . | | V_c . | |<-----| | . |
+------.-| Clock | y | Phase/Freq |<---------+ +------.-| Clock | y | Phase/Freq |<---------+
. | Adjust |<-----| Prediction | . . | Adjust |<-----| Prediction | .
. | | | | . . | | | | .
. +---------+ +-------------+ . . +---------+ +-------------+ .
....................................... .......................................
Figure 31: Clock Discipline Feedback Loop Figure 29: Clock Discipline Feedback Loop
Ordinarily, the pseudo-linear feedback loop described above operates Ordinarily, the pseudo-linear feedback loop described above operates
to discipline the system clock. However, there are cases where a to discipline the system clock. However, there are cases where a
nonlinear algorithm offers considerable improvement. One case is nonlinear algorithm offers considerable improvement. One case is
when the discipline starts without knowledge of the intrinsic clock when the discipline starts without knowledge of the intrinsic clock
frequency. The pseudo-linear loop takes several hours to develop an frequency. The pseudo-linear loop takes several hours to develop an
accurate measurement and during most of that time the poll interval accurate measurement and during most of that time the poll interval
cannot be increased. The nonlinear loop described below does this in cannot be increased. The nonlinear loop described below does this in
15 minutes. Another case is when occasional bursts of large jitter 15 minutes. Another case is when occasional bursts of large jitter
are present due to congested network links. The state machine are present due to congested network links. The state machine
described below resists error bursts lasting less than 15 minutes. described below resists error bursts lasting less than 15 minutes.
Figure 32 contains a summary of the variables and parameters Figure 30 contains a summary of the variables and parameters
including the variables (lower case) or parameters (upper case) name, including the variables (lower case) or parameters (upper case) name,
formula name and short description. Unless noted otherwise, all formula name and short description. Unless noted otherwise, all
variables have assumed prefix c. The variables t, tc, state, hyster variables have assumed prefix c. The variables t, tc, state, hyster
and count are integers; the remaining variables are floating doubles. and count are integers; the remaining variables are floating doubles.
The function of each will be explained in the algorithm descriptions The function of each will be explained in the algorithm descriptions
below. below.
+--------+------------+--------------------------+ +--------+------------+--------------------------+
| Name | Formula | Description | | Name | Formula | Description |
+--------+------------+--------------------------+ +--------+------------+--------------------------+
skipping to change at page 50, line 27 skipping to change at page 48, line 27
| hyster | hyster | hysteresis counter | | hyster | hyster | hysteresis counter |
| STEPT | 125 | step threshold (.125 s) | | STEPT | 125 | step threshold (.125 s) |
| WATCH | 900 | stepout thresh(s) | | WATCH | 900 | stepout thresh(s) |
| PANICT | 1000 | panic threshold (1000 s) | | PANICT | 1000 | panic threshold (1000 s) |
| LIMIT | 30 | hysteresis limit | | LIMIT | 30 | hysteresis limit |
| PGATE | 4 | hysteresis gate | | PGATE | 4 | hysteresis gate |
| TC | 16 | time constant scale | | TC | 16 | time constant scale |
| AVG | 8 | averaging constant | | AVG | 8 | averaging constant |
+--------+------------+--------------------------+ +--------+------------+--------------------------+
Figure 32: Clock Discipline Variables and Parameters Figure 30: Clock Discipline Variables and Parameters
The discipline is implemented by the local_clock() routine, which is The discipline is implemented by the local_clock() routine, which is
called from the clock_update() routine. The local_clock() routine in called from the clock_update() routine. The local_clock() routine in
Appendix A.5.5.6 has two parts; the first implements the clock state Appendix A.5.5.6 has two parts; the first implements the clock state
machine and the second determines the time constant and thus the poll machine and the second determines the time constant and thus the poll
interval. interval.
The local_clock() routine exits immediately if the offset is greater The local_clock() routine exits immediately if the offset is greater
than the panic threshold PANICT (1000 s). The state transition than the panic threshold PANICT (1000 s). The state transition
function is implemented by the rstclock() function in function is implemented by the rstclock() function in
Appendix A.5.5.7. Figure 33 shows the state transition function used Appendix A.5.5.7. Figure 31 shows the state transition function used
by this routine. It has four columns showing respectively the state by this routine. It has four columns showing respectively the state
name, predicate and action if the offset theta is less than the step name, predicate and action if the offset theta is less than the step
threshold, the predicate and actions otherwise, and finally some threshold, the predicate and actions otherwise, and finally some
comments. comments.
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
| State | theta < STEP | theta > STEP | Comments | | State | theta < STEP | theta > STEP | Comments |
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
| NSET | ->FREQ | ->FREQ | no frequency | | NSET | ->FREQ | ->FREQ | no frequency |
| | adjust time | step time | file | | | adjust time | step time | file |
skipping to change at page 51, line 30 skipping to change at page 49, line 30
| | else ->SYNC | else ->SYNC | frequency | | | else ->SYNC | else ->SYNC | frequency |
| | step freq | step freq | | | | step freq | step freq | |
| | adjust time | adjust time | | | | adjust time | adjust time | |
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
| SYNC | ->SYNC | if < 900 s ->SPIK | normal | | SYNC | ->SYNC | if < 900 s ->SPIK | normal |
| | adjust freq | else ->SYNC | operation | | | adjust freq | else ->SYNC | operation |
| | adjust time | step freq | | | | adjust time | step freq | |
| | | step time | | | | | step time | |
+-------+---------------------+-------------------+--------------+ +-------+---------------------+-------------------+--------------+
Figure 33: State Transition Function Figure 31: State Transition Function
In the table entries the next state is identified by the arrow -> In the table entries the next state is identified by the arrow ->
with the actions listed below. Actions such as adjust time and with the actions listed below. Actions such as adjust time and
adjust frequency are implemented by the PLL/FLL feedback loop in the adjust frequency are implemented by the PLL/FLL feedback loop in the
local_clock() routine. A step clock action is implemented by setting local_clock() routine. A step clock action is implemented by setting
the clock directly, but this is done only after the stepout threshold the clock directly, but this is done only after the stepout threshold
WATCH (900 s) when the offset is more than the step threshold STEPT WATCH (900 s) when the offset is more than the step threshold STEPT
(.125 s). This resists clock steps under conditions of extreme (.125 s). This resists clock steps under conditions of extreme
network congestion. network congestion.
skipping to change at page 52, line 35 skipping to change at page 50, line 35
13. Poll Process 13. Poll Process
Each association supports a poll process that runs at regular Each association supports a poll process that runs at regular
intervals to construct and send packets in symmetric, client and intervals to construct and send packets in symmetric, client and
broadcast server associations. It runs continuously, whether or not broadcast server associations. It runs continuously, whether or not
servers are reachable in order to manage the clock filter and reach servers are reachable in order to manage the clock filter and reach
register. register.
13.1. Poll Process Variables 13.1. Poll Process Variables
Figure 34 summarizes the common names, formula names and a short Figure 32 summarizes the common names, formula names and a short
description of the poll process variables(lower case) and parameters description of the poll process variables(lower case) and parameters
(upper case). Unless noted otherwise, all variables have assumed (upper case). Unless noted otherwise, all variables have assumed
prefix p. prefix p.
+---------+---------+--------------------+ +---------+---------+--------------------+
| Name | Formula | Description | | Name | Formula | Description |
+---------+---------+--------------------+ +---------+---------+--------------------+
| hpoll | hpoll | host poll exponent | | hpoll | hpoll | host poll exponent |
| last | last | last poll time | | last | last | last poll time |
| next | next | next poll time | | next | next | next poll time |
| reach | reach | reach register | | reach | reach | reach register |
| unreach | unreach | unreach counter | | unreach | unreach | unreach counter |
| UNREACH | 24 | unreach limit | | UNREACH | 24 | unreach limit |
| BCOUNT | 8 | burst count | | BCOUNT | 8 | burst count |
| BURST | flag | burst enable | | BURST | flag | burst enable |
| IBURST | flag | iburst enable | | IBURST | flag | iburst enable |
+---------+---------+--------------------+ +---------+---------+--------------------+
Figure 34: Poll Process Variables and Parameters Figure 32: Poll Process Variables and Parameters
The poll process variables are allocated in the association data The poll process variables are allocated in the association data
structure along with the peer process variables. Following is a structure along with the peer process variables. Following is a
detailed description of the variables. The parameters will be called detailed description of the variables. The parameters will be called
out in the following text. out in the following text.
hpoll: signed integer representing the poll exponent, in log2 seconds hpoll: signed integer representing the poll exponent, in log2 seconds
last: integer representing the seconds counter when the most recent last: integer representing the seconds counter when the most recent
packet was sent packet was sent
skipping to change at page 54, line 43 skipping to change at page 52, line 43
server is reachable and unreach is set to zero; otherwise, unreach is server is reachable and unreach is set to zero; otherwise, unreach is
incremented by one for each poll to the maximum UNREACH. Thereafter incremented by one for each poll to the maximum UNREACH. Thereafter
for each poll hpoll is increased by one, which doubles the poll for each poll hpoll is increased by one, which doubles the poll
interval up to the maximum MAXPOLL determined by the poll_update() interval up to the maximum MAXPOLL determined by the poll_update()
routine. When the server again becomes reachable, unreach is set to routine. When the server again becomes reachable, unreach is set to
zero, hpoll is reset to the tc system variable and operation resumes zero, hpoll is reset to the tc system variable and operation resumes
normally. normally.
A packet is sent by the xmit_packet() routine in Appendix A.3. Some A packet is sent by the xmit_packet() routine in Appendix A.3. Some
header values are copied from the peer variables left by a previous header values are copied from the peer variables left by a previous
packet and others from the system variables. Figure 35 shows which packet and others from the system variables. Figure 33 shows which
values are copied to each header field. In those implementations values are copied to each header field. In those implementations
using floating double data types for root delay and root dispersion, using floating double data types for root delay and root dispersion,
these must be converted to NTP short format. All other fields are these must be converted to NTP short format. All other fields are
either copied intact from peer and system variables or struck as a either copied intact from peer and system variables or struck as a
timestamp from the system clock. timestamp from the system clock.
+-----------------------------------+ +-----------------------------------+
| Packet Variable <-- Variable | | Packet Variable <-- Variable |
+-----------------------------------+ +-----------------------------------+
| x.leap <-- s.leap | | x.leap <-- s.leap |
skipping to change at page 55, line 25 skipping to change at page 53, line 25
| x.rootdisp <-- s.rootdisp | | x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid | | x.refid <-- s.refid |
| x.reftime <-- s.reftime | | x.reftime <-- s.reftime |
| x.org <-- p.xmt | | x.org <-- p.xmt |
| x.rec <-- p.dst | | x.rec <-- p.dst |
| x.xmt <-- clock | | x.xmt <-- clock |
| x.keyid <-- p.keyid | | x.keyid <-- p.keyid |
| x.digest <-- md5 digest | | x.digest <-- md5 digest |
+-----------------------------------+ +-----------------------------------+
Figure 35: xmit_packet Packet Header Figure 33: xmit_packet Packet Header
The poll_update() routine shown in Appendix A.5.7.2 is called when a The poll_update() routine shown in Appendix A.5.7.2 is called when a
valid packet is received and immediately after a poll message has valid packet is received and immediately after a poll message has
been sent. If in a burst, the poll interval is fixed at 2 s; been sent. If in a burst, the poll interval is fixed at 2 s;
otherwise, the host poll exponent hpoll is set to the minimum of otherwise, the host poll exponent hpoll is set to the minimum of
ppoll from the last packet received and hpoll from the poll() ppoll from the last packet received and hpoll from the poll()
routine, but not less than MINPOLL nor greater than MAXPOLL. Thus routine, but not less than MINPOLL nor greater than MAXPOLL. Thus
the clock discipline can be oversampled, but not undersampled. This the clock discipline can be oversampled, but not undersampled. This
is necessary to preserve subnet dynamic behavior and protect against is necessary to preserve subnet dynamic behavior and protect against
protocol errors. protocol errors.
The poll exponent is converted to an interval which when added to the The poll exponent is converted to an interval which when added to the
last variable determines the next variable and thus the time for the last variable determines the next variable and thus the time for the
next poll. Finally, the last variable is set to the current seconds next poll. Finally, the last variable is set to the current seconds
counter. counter.
14. Security Considerations 14. Simple Network Time Protocol (SNTP)
Primary servers and clients complying with a subset of NTP, called
the Simple Network Time Protocol (SNTPv4) [2], do not need to
implement the mitigation algorithms described in Section 9 and
following sections. SNTP is intended for primary servers equipped
with a single reference clock, as well as for clients with a single
upstream server and no dependent clients. The fully developed NTPv4
implementation is intended for secondary servers with multiple
upstream servers and multiple downstream servers or clients. Other
than these considerations, NTP and SNTP servers and clients are
completely interoperable and can be intermixed in NTP subnets.
An SNTP primary server implementing the on-wire protocol described in
Section 8 has no upstream servers except a single reference clock.
In principle, it is indistinguishable from an NTP primary server that
has the mitigation algorithms and therefore capable of mitigating
between multiple reference clocks.
Upon receiving a client request, an SNTP primary server constructs
and sends the reply packet as described in Figure 34. Note that the
dispersion field in the packet header must be updated as described in
Section 5.
+-----------------------------------+
| Packet Variable <-- Variable |
+-----------------------------------+
| x.leap <-- s.leap |
| x.version <-- r.version |
| x.mode <-- 4 |
| x.stratum <-- s.stratum |
| x.poll <-- r.poll |
| x.precision <-- s.precision |
| x.rootdelay <-- s.rootdelay |
| x.rootdisp <-- s.rootdisp |
| x.refid <-- s.refid |
| x.reftime <-- s.reftime |
| x.org <-- r.xmt |
| x.rec <-- r.dst |
| x.xmt <-- clock |
| x.keyid <-- r.keyid |
| x.digest <-- md5 digest |
+-----------------------------------+
Figure 34: fast_xmit Packet Header
A SNTP client implementing the on-wire protocol has a single server
and no dependent clients. It can operate with any subset of the NTP
on-wire protocol, the simplest approach using only the transmit
timestamp of the server packet and ignoring all other fields.
However, the additional complexity to implement the full on-wire
protocol is minimal so that a full implementation is encouraged.
15. Security Considerations
NTPv4 provides an optional authentication field that utilizes the MD5 NTPv4 provides an optional authentication field that utilizes the MD5
algorithm. MD5, as the case for SHA-1, is derived from MD4, which algorithm. MD5, as the case for SHA-1, is derived from MD4, which
has long been known to be weak. In 2004, techniques for efficiently has long been known to be weak. In 2004, techniques for efficiently
finding collisions in MD5 were announced. A summary of the finding collisions in MD5 were announced. A summary of the
apropriateness of MD5 can be found in [10]. apropriateness of MD5 can be found in [9].
In the case of NTP as specified herein, NTP broadcast clients are In the case of NTP as specified herein, NTP broadcast clients are
vulnerable to disruption by misbehaving or hostile SNTP or NTP vulnerable to disruption by misbehaving or hostile SNTP or NTP
broadcast servers elsewhere in the Internet. Access controls and/or broadcast servers elsewhere in the Internet. Access controls and/or
cryptographic authentication means should be provided for additional cryptographic authentication means should be provided for additional
security in such cases. security in such cases.
15. IANA Considerations Section 8 describes a potential security concern with the replay of
client requests. Following the recommendations in that section
provides protection against such attacks.
16. IANA Considerations
UDP/TCP Port 123 was previously assigned by IANA for this protocol. UDP/TCP Port 123 was previously assigned by IANA for this protocol.
The IANA has assigned the IPv4 multicast group address 224.0.1.1 and The IANA has assigned the IPv4 multicast group address 224.0.1.1 and
the IPv6 multicast address ending :101 for NTP. This document the IPv6 multicast address ending :101 for NTP. This document
introduces NTP extension fields allowing for the development of introduces NTP extension fields allowing for the development of
future extensions to the protocol, where a particular extension is to future extensions to the protocol, where a particular extension is to
be identified by the Field Type sub-field within the extension field. be identified by the Field Type sub-field within the extension field.
IANA is requested to establish and maintain a registry for Extension IANA is requested to establish and maintain a registry for Extension
Field Types associated with this protocol, populating this registry Field Types associated with this protocol, populating this registry
with no initial entries. As future needs arise, new Extension Field with no initial entries. As future needs arise, new Extension Field
Types may be defined. Following the policies outlined in [11], new Types may be defined. Following the policies outlined in [10], new
consensus. values are to be defined by IETF consensus.
16. Acknowledgements The IANA is requested to create a new registry for NTP Kiss-o'-Death
codes. This should include the current codes defined in Section 7.4,
and may be extended on a FCFS basis. The format of the registry is:
+------+------------------------------------------------------------+
| Code | Meaning |
+------+------------------------------------------------------------+
| ACST | The association belongs to a unicast server |
| AUTH | Server authentication failed |
| ... | ... |
+------+------------------------------------------------------------+
Figure 35: Kiss Codes
17. Acknowledgements
The editors would like to thank Karen O'Donoghue, Brian Haberman, The editors would like to thank Karen O'Donoghue, Brian Haberman,
Greg Dowd, Mark Elliot, and Harlan Stenn for technical reviews of Greg Dowd, Mark Elliot, and Harlan Stenn for technical reviews of
this document. this document.
17. Informative References 18. References
18.1. Informative References
[1] Mills, D., "Network Time Protocol (Version 3) Specification, [1] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992. Implementation", RFC 1305, March 1992.
[2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for [2] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 and OSI", RFC 4330, January 2006. IPv4, IPv6 and OSI", RFC 4330, January 2006.
[3] Mills, D.L., "The Autokey security architecture, protocol and [3] Mills, D.L., "The Autokey security architecture, protocol and
algorithms. Electrical and Computer Engineering Technical algorithms. Electrical and Computer Engineering Technical
Report 06-1-1", NDSS , January 2006. Report 06-1-1", NDSS , January 2006.
[4] Mills, D.L., Electrical and Computer Engineering Technical [4] Mills, D.L., Electrical and Computer Engineering Technical
Report 06-6-1, NDSS, June 2006., "Network Time Protocol Version Report 06-6-1, NDSS, June 2006., "Network Time Protocol Version
4 Reference and Implementation Guide.", 2006. 4 Reference and Implementation Guide.", 2006.
[5] Mills, D.L., "Computer Network Time Synchronization - the [5] Mills, D.L., "Computer Network Time Synchronization - the
Network Time Protocol. CRC Press, 304pp.", 2006. Network Time Protocol. CRC Press, 304pp.", 2006.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement [6] International Telecommunications Union, "ITU-R TF.460 Standard-
Levels", BCP 14, RFC 2119, March 1997. frequency and time-signal emissions", February 2002.
[7] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [7] Bureau International des Poids et Mesures, "Comptes Rendus de
April 1992. la 15e CGPM", 1976.
[9] Marzullo and S. Owicki, "Maintaining the time in a distributed [8] Marzullo and S. Owicki, "Maintaining the time in a distributed
system.", ACM Operating Systems Review 19 , July 1985. system.", ACM Operating Systems Review 19 , July 1985.
[10] Bellovin, S. and E. Rescorla, Proceedings of the 13th annual [9] Bellovin, S. and E. Rescorla, Proceedings of the 13th annual
ISOC Network and Distributed System Security Symposium, ISOC Network and Distributed System Security Symposium,
"Deploying a new Hash Algorithm", February 2006. "Deploying a new Hash Algorithm", February 2006.
[11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
18.2. Normative References
[11] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[12] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[13] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[15] Simonsen, K., "Character Mnemonics and Character Sets",
RFC 1345, June 1992.
[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
Appendix A. Code Skeleton Appendix A. Code Skeleton
This appendix is intended to describe the protocol and algorithms of This appendix is intended to describe the protocol and algorithms of
an implementation in a general way using what is called a code an implementation in a general way using what is called a code
skeleton program. This consists of a set of definitions, structures skeleton program. This consists of a set of definitions, structures
and code fragments which illustrate the protocol operations without and code fragments which illustrate the protocol operations without
the complexities of an actual implementation of the protocol. This the complexities of an actual implementation of the protocol. This
program is not an executable and is not designed to run in the program is not an executable and is not designed to run in the
ordinary sense. It is designed to be compiled only in order to ordinary sense. It is designed to be compiled only in order to
verify consistent variable and type usage. verify consistent variable and type usage.
skipping to change at page 93, line 43 skipping to change at page 93, line 43
z += p->offset / x; z += p->offset / x;
w += SQUARE(p->offset - s.v[0].p->offset) / x; w += SQUARE(p->offset - s.v[0].p->offset) / x;
} }
s.offset = z / y; s.offset = z / y;
s.jitter = SQRT(w / y); s.jitter = SQRT(w / y);
} }
A.5.5.6. local_clock() A.5.5.6. local_clock()
/* /*
* Clock discipoine parameters and constants * Clock discipline parameters and constants
*/ */
#define STEPT .128 /* step threshold (s) */ #define STEPT .128 /* step threshold (s) */
#define WATCH 900 /* stepout threshold (s) */ #define WATCH 900 /* stepout threshold (s) */
#define PANICT 1000 /* panic threshold (s) */ #define PANICT 1000 /* panic threshold (s) */
#define PLL 65536 /* PLL loop gain */ #define PLL 65536 /* PLL loop gain */
#define FLL MAXPOLL + 1 /* FLL loop gain */ #define FLL MAXPOLL + 1 /* FLL loop gain */
#define AVG 4 /* parameter averaging constant */ #define AVG 4 /* parameter averaging constant */
#define ALLAN 1500 /* compromise Allan intercept (s) */ #define ALLAN 1500 /* compromise Allan intercept (s) */
#define LIMIT 30 /* poll-adjust threshold */ #define LIMIT 30 /* poll-adjust threshold */
 End of changes. 153 change blocks. 
397 lines changed or deleted 412 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/