assoc.adoc 11.2 KB
Newer Older
James Browning's avatar
James Browning committed
1
= Association Management
2
include::html.include[]
3 4 5 6

[cols="10%,90%",frame="none",grid="none",style="verse"]
|==============================
|image:pic/alice51.gif[]|
7
{millshome}pictures.html[from 'Alice's Adventures in Wonderland', Lewis Carroll]
8 9 10 11 12 13

Make sure who your friends are.

|==============================


James Browning's avatar
James Browning committed
14
== Related Links
15

16
include::includes/hand.adoc[]
17

James Browning's avatar
James Browning committed
18
== Table of Contents
19 20 21 22 23 24 25 26 27 28 29 30

* link:#modes[Association Modes]
* link:#client[Client/Server Mode]
* link:#symact[Symmetric Active/Passive Mode]
* link:#broad[Broadcast/Multicast Modes]
* link:#many[Manycast Mode]
* link:#poll[Poll Interval Management]
* link:#burst[Burst Options]

'''''

[[modes]]
James Browning's avatar
James Browning committed
31
== Association Modes
32 33 34 35

This page describes the various modes of operation provided in NTPv4.
There are three types of associations in NTP: _persistent_,
_preemptable_ and _ephemeral_. Persistent associations are mobilized by
36 37
a configuration command and never demobilized. Preemptable associations
are mobilized by a configuration command which
38
includes the +preempt+ option or upon arrival of an automatic server
Paul Theodoropoulos's avatar
Paul Theodoropoulos committed
39
discovery packet. They are demobilized by timeout or when preempted
40
by a "better" server, as described on the link:discover.html[Automatic
41
Server Discovery Schemes] page.
42

43 44 45 46 47 48
There are two principal modes of operation in NTP: client/server and
broadcast. There are three automatic server discovery schemes in NTP:
broadcast and pool described on the link:discover.html[Automatic
Server Discovery Schemes] page. In addition, the link:#burst[burst
options] and link:orphan.html[orphan mode] can be used in appropriate
cases.
49 50 51 52 53 54 55

Following is a summary of the operations in each mode. Note that
reference to option applies to the commands described on the
link:confopt.html[Server Commands and Options] page. See that page for
applicability and defaults.

[[client]]
James Browning's avatar
James Browning committed
56
== Client/Server Mode
57 58 59 60 61 62 63 64 65

Client/server mode is the most common configuration in the Internet
today. It operates in the classic remote-procedure-call (RPC) paradigm
with stateless servers and stateful clients. In this mode a host sends a
client (mode 3) request to the specified server and expects a server
(mode 4) reply at some future time. In some contexts this would be
described as a "pull" operation, in that the host pulls the time and
related values from the server.

66 67 68 69 70
A host is configured in client mode using the +server+ (sic)
or +pool+ command and specifying the server DNS name or IPv4 or
IPv6 address; the server requires no prior configuration (but
see link:access.html[Access Control]). The +iburst+ option described
later on this page is recommended for clients, as this speeds up initial
71
synchronization from several minutes to several seconds. The +burst+
72 73 74 75
option described later on this page can be useful to reduce jitter on
very noisy dial-up or ISDN network links.

Ordinarily, the program automatically manages the poll interval between
76
the default minimum and maximum values. The +minpoll+ and +maxpoll+
77 78 79 80
options can be used to bracket the range. Unless noted otherwise, these
options should not be used with reference clock drivers.

[[symact]]
James Browning's avatar
James Browning committed
81
== Symmetric Active/Passive Mode
82 83 84 85

Symmetric active/passive mode is intended for configurations where a
clique of low-stratum peers operate as mutual backups for each other.
Each peer operates with one or more primary reference sources, such as a
Paul Theodoropoulos's avatar
Paul Theodoropoulos committed
86
reference clock, or a set of secondary (stratum 2) servers known to be
87 88 89 90 91 92 93 94 95 96 97
reliable and authentic. Should one of the peers lose all reference
sources or simply cease operation, the other peers will automatically
reconfigure so that time and related values can flow from the surviving
peers to all hosts in the subnet. In some contexts this would be
described as a "push-pull" operation, in that the peer either pulls or
pushes the time and related values depending on the particular
configuration.

A symmetric active peer sends a symmetric active (mode 1) message to a
designated peer. If a matching configured symmetric active association
is found, the designated peer returns a symmetric active message. If no
Paul Theodoropoulos's avatar
Paul Theodoropoulos committed
98
matching association is found, the designated peer mobilizes an ephemeral
99 100 101 102 103
symmetric passive association and returns a symmetric passive (mode 2)
message. Since an intruder can impersonate a symmetric active peer and
cause a spurious symmetric passive association to be mobilized,
symmetric passive mode should always be cryptographically validated.

104 105 106 107 108
Due to unresolvable security issues with symmetric mode, NTPsec
includes only partial support for it. The deprecated +peer+ directive
which formerly set up a symmetric active association is now a synonym
for +server+. Servers which receive symmetric active messages will
immediately reply with symmetric passive responses without setting up
109
any new association; essentially they treat such messages exactly
Paul Theodoropoulos's avatar
Paul Theodoropoulos committed
110
like client-mode messages, aside from putting a different mode number
111
into the response.
112 113

[[broad]]
James Browning's avatar
James Browning committed
114
== Broadcast/Multicast Modes
115

116 117 118 119 120
These modes cannot be effectively secured and are deprecated in
NTPsec.  Client-mode support has been removed; server-side support
is retained for backward compatibility but may be removed in a
future release.

121
NTP broadcast modes are intended for configurations
122 123 124
involving one or a few servers and a possibly very large client
population. Broadcast mode can be used with Ethernet, FDDI and WiFi
spans interconnected by hubs or switches. Ordinarily, broadcast packets
125
do not extend beyond a level-3 router.
126

127 128
A server is configured to send broadcast messages using the
+broadcast+ command and specifying the subnet address for broadcast.
129 130

[[many]]
James Browning's avatar
James Browning committed
131
== Manycast and Pool Modes
132 133

Manycast and pool modes are automatic discovery and configuration
134 135 136 137
paradigms. They are intended as a means for a client to troll the
nearby network neighborhood to find cooperating willing servers,
validate them using cryptographic means and evaluate their time values
with respect to other servers that might be lurking in the
138 139 140 141 142 143 144
vicinity. The intended result is that each client mobilizes ephemeral
client associations with some number of the "best" of the nearby
servers, yet automatically reconfigures to sustain this number of
servers should one or another fail. Additional information is on the
link:discover.html[Automatic Server Discovery Schemes] page.

[[poll]]
James Browning's avatar
James Browning committed
145
== Poll Interval Management
146 147 148 149

NTP uses an intricate heuristic algorithm to automatically control the
poll interval for maximum accuracy consistent with minimum network
overhead. The algorithm measures the incidental offset and jitter to
150
determine the best poll interval. When +ntpd+ starts, the interval is
151
the default minimum 64 sec. Under normal conditions when the clock
152
discipline has stabilized, the interval increases in steps to the
153
default maximum 1024 sec. In addition, should a server become unreachable
154 155 156 157 158 159 160 161 162
after some time, the interval increases in steps to the maximum in order
to reduce network overhead. Additional information about the algorithm
is on the link:poll.html[Poll Program] page.

The default poll interval range is suitable for most conditions, but can
be changed using options on the link:confopt.html[Server Commands and
Options] and link:miscopt.html[Miscellaneous Options] pages. However,
when using maximum intervals much larger than the default, the residual
clock frequency error must be small enough for the discipline loop to
163
capture and correct. The capture range is 500 PPM with a 64-sec interval
164 165 166 167 168
decreasing by a factor of two for each interval doubling. At a 36-hr
interval, for example, the capture range is only 0.24 PPM.

In the NTPv4 specification and reference implementation, the poll
interval is expressed in log~2~ units, properly called the _poll
169 170
exponent._ It is constrained by the lower limit +minpoll+ and upper
limit +maxpoll+ options of the link:confopt.html[+server+] command. The
171
limits default to 6 (64 sec) and 10 (1024 sec), respectively, which are
172 173 174 175 176 177 178 179 180 181 182 183 184 185
appropriate for the vast majority of cases.

As a rule of thumb, the expected errors increase by a factor of two as
the poll interval increases by a factor of four. The poll interval
algorithm slowly increases the poll interval when jitter dominates the
error budget, but quickly reduces the interval when wander dominates it.
More information about this algorithm is on the link:warp.html[How NTP
Works] page.

There is normally no need to change the poll limits, as the poll
interval is managed automatically as a function of prevailing jitter and
wander. The most common exceptions are the following.

* With fast, lightly loaded LANs and modern processors, the nominal
186 187
Allan intercept is about 500 sec. In these cases the expected errors can
be further reduced using a poll exponent of 4 (16 sec). In the case of the
188 189 190
pulse-per-second (PPS) driver, this is the recommended value.
* With symmetric modes the most stable behavior results when both peers
are configured in symmetric active mode with matching poll intervals of
191
6 (64 sec).
192 193 194 195 196 197
* The poll interval should not be modified for reference clocks, with
the single exception the ACTS telephone modem driver. In this case the
recommended minimum and maximum intervals are 12 (1.1 hr) and 17 (36
hr), respectively.

[[burst]]
James Browning's avatar
James Browning committed
198
== Burst Options
199 200

Occasionally it is necessary to send packets temporarily at intervals
201 202
less than the poll interval. For instance, with the +burst+ and +iburst+
options of the link:confopt.html[+server+] command, the poll program
Paul Theodoropoulos's avatar
Paul Theodoropoulos committed
203
sends a burst of several packets at 2 second intervals. In either case the
204 205 206 207 208 209 210 211 212 213
poll program avoids sending needless packets if the server is not
responding. The client begins a burst with a single packet. When the
first packet is received from the server, the client continues with the
remaining packets in the burst. If the first packet is not received
within 64 s, it will be sent again for two additional retries before
beginning backoff. The result is to minimize network load if the server
is not responding. Additional details are on the link:poll.html[Poll
Program] page.

There are two burst options where a single poll event triggers a burst.
214
They should be used only with the +server+ and +pool+ commands, but not
215 216 217 218 219 220
with reference clock drivers nor symmetric mode peers. In both modes,
received server packets update the clock filter, which selects the best
(most accurate) time values. When the last packet in the burst is sent,
the next received packet updates the system variables and adjusts the
system clock as if only a single packet exchange had occurred.

221
The +iburst+ option is useful where the system clock must be set quickly
222 223
or when the network attachment requires an initial calling or training
sequence, as in PPP or ISDN services. In general, this option is
224
recommended for +server+ and +pool+ commands. A burst is sent only when
225 226 227 228 229
the server is unreachable; in particular, when first starting up.
Ordinarily, the clock is set within a few seconds after the first
received packet. See the link:clock.html[Clock State Machine] page for
further details about the startup behavior.

230
The +burst+ option is useful in cases of severe network jitter or when
231 232
the network attachment requires an initial calling or training sequence.
This option is recommended when the minimum poll exponent is larger than
233
10 (1024 sec). A burst is sent only when the server is reachable. The
234 235 236 237 238 239
number of packets in the burst is determined by the poll interval so
that the average interval between packets (headway) is no less than the
minimum poll interval for the association.

'''''

240
include::includes/footer.adoc[]