xref: /freebsd/contrib/ntp/html/assoc.html (revision 9c2daa00)
19c2daa00SOllivier Robert<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
29c2daa00SOllivier Robert<html>
39c2daa00SOllivier Robert<head>
49c2daa00SOllivier Robert<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
59c2daa00SOllivier Robert<meta name="generator" content="HTML Tidy, see www.w3.org">
69c2daa00SOllivier Robert<title>Association Management</title>
79c2daa00SOllivier Robert<link href="scripts/style.css" type="text/css" rel="stylesheet">
89c2daa00SOllivier Robert</head>
99c2daa00SOllivier Robert<body>
109c2daa00SOllivier Robert<h3>Association Management</h3>
119c2daa00SOllivier Robert<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/~mills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
129c2daa00SOllivier Robert<p>Make sure who your friends are.</p>
139c2daa00SOllivier Robert<p>Last update:
149c2daa00SOllivier Robert  <!-- #BeginDate format:En2m -->31-Jan-2014  06:54<!-- #EndDate -->
159c2daa00SOllivier Robert    UTC</p>
169c2daa00SOllivier Robert<br clear="left">
179c2daa00SOllivier Robert<h4>Related Links</h4>
189c2daa00SOllivier Robert<script type="text/javascript" language="javascript" src="scripts/hand.txt"></script>
199c2daa00SOllivier Robert<script type="text/javascript" language="javascript" src="scripts/config.txt"></script>
209c2daa00SOllivier Robert<h4>Table of Contents</h4>
219c2daa00SOllivier Robert<ul>
229c2daa00SOllivier Robert  <li class="inline"><a href="#modes">Association Modes</a></li>
239c2daa00SOllivier Robert  <li class="inline"><a href="#client">Client/Server Mode</a></li>
249c2daa00SOllivier Robert  <li class="inline"><a href="#symact">Symmetric Active/Passive Mode</a></li>
259c2daa00SOllivier Robert  <li class="inline"><a href="#broad">Broadcast/Multicast Modes</a></li>
269c2daa00SOllivier Robert  <li class="inline"><a href="#many">Manycast Mode</a></li>
279c2daa00SOllivier Robert  <li class="inline"><a href="#poll">Poll Interval Management</a></li>
289c2daa00SOllivier Robert  <li class="inline"><a href="#burst">Burst Options</a></li>
299c2daa00SOllivier Robert</ul>
309c2daa00SOllivier Robert<hr>
319c2daa00SOllivier Robert<h4 id="modes">Association Modes</h4>
329c2daa00SOllivier Robert<p>This page describes the various modes of operation provided in NTPv4. There are three types of associations in NTP: <em>persistent</em>, <em>preemptable</em> and <em>ephemeral</em>. Persistent associations are mobilized by a configuration command and never demobilized. Preemptable associations, which are new to NTPv4, are mobilized by a configuration command which includes the <tt>preempt</tt> option or upon arrival of an automatic server discovery packet. They are are demobilized by timeout or when preempted by  a &quot;better&quot; server, as described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. Ephemeral associations are mobilized upon arrival of   broadcast or multicast server packets and demobilized by timeout.</p>
339c2daa00SOllivier Robert<p>Ordinarily, successful mobilization of ephemeral associations requires the server to be cryptographically authenticated to the client. This can be done using either symmetric key or Autokey public key cryptography, as described on the <a href="authentic.html">Authentication Support</a> page.</p>
349c2daa00SOllivier Robert<p>There are three principal modes of operation in NTP: client/server, symmetric active/passive and broadcast/multicast. There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and pool described on the <a href="discover.html">Automatic Server Discovery Schemes</a> page. In addition, the <a href="#burst">burst options</a> and <a href="orphan.html">orphan mode</a> can be used in appropriate cases.</p>
359c2daa00SOllivier Robert<p>Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the <a href="confopt.html">Server Commands and  Options</a> page. See that page for applicability and defaults.</p>
369c2daa00SOllivier Robert<h4 id="client">Client/Server Mode</h4>
379c2daa00SOllivier Robert<p>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 &quot;pull&quot; operation, in that the host pulls the time and related values from the server.</p>
389c2daa00SOllivier Robert<p>A host is configured in client mode using the <tt>server</tt> (sic) command and specifying the server DNS&nbsp;name or IPv4 or IPv6 address; the server requires no prior configuration. The <tt>iburst</tt> option described later on this page is recommended for clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt> option described later on this page can be useful to reduce jitter on very noisy dial-up or ISDN network links.</p>
399c2daa00SOllivier Robert<p>Ordinarily, the program automatically manages the poll interval between the default minimum and maximum values. The <tt>minpoll</tt> and <tt>maxpoll</tt> options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.</p>
409c2daa00SOllivier Robert<h4 id="symact">Symmetric Active/Passive Mode</h4>
419c2daa00SOllivier Robert<p>Symmetric active/passive mode is intended for configurations where a clique
429c2daa00SOllivier Robert  of low-stratum peers operate as mutual backups for each other. Each peer operates
439c2daa00SOllivier Robert  with one or more primary reference sources, such as a reference clock, or a set
449c2daa00SOllivier Robert  of secondary (stratum, 2) servers known to be reliable and authentic. Should
459c2daa00SOllivier Robert  one of the peers lose all reference sources or simply cease operation, the
469c2daa00SOllivier Robert  other peers will automatically reconfigure so that time and related values
479c2daa00SOllivier Robert  can flow from the surviving peers to all hosts in the subnet. In some contexts
489c2daa00SOllivier Robert  this would be described as a &quot;push-pull&quot; operation, in that the
499c2daa00SOllivier Robert  peer either pulls or pushes the time and related values depending on the particular
509c2daa00SOllivier Robert  configuration.</p>
519c2daa00SOllivier Robert<p>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 matching association is found, the designated peer mobilizes a ephemeral 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.</p>
529c2daa00SOllivier Robert<p>A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS name or IPv4 or IPv6 address. The <tt>burst</tt> and <tt>iburst</tt> options should not be used in symmetric modes, as this can upset the intended symmetry of the protocol and result in spurious duplicate or dropped messages.</p>
539c2daa00SOllivier Robert<p>As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the <tt>minpoll</tt> and <tt>maxpoll</tt> options.</p>
549c2daa00SOllivier Robert<h4 id="broad">Broadcast/Multicast Modes</h4>
559c2daa00SOllivier Robert<p>NTP broadcast and multicast modes are intended for configurations 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 do not extend beyond a level-3 router. Where service is intended beyond a level-3 router, multicast mode can be used. Additional information is on the <a href="discover.html">Automatic NTP Configuration Options</a> page.</p>
569c2daa00SOllivier Robert<p>A server is configured to send broadcast or multicast messages  using the <tt>broadcast</tt> command and specifying the subnet address for broadcast  or the multicast group address for multicast. A broadcast client is enabled using the <a href="confopt.html#broadcastclient"><tt>broadcastclient</tt></a> command, while a multicast client is enabled using the <a href="confopt.html#multicastclient"><tt>multicastclient</tt></a> command and specifying the multicast group address. Multiple commands of either type can be used. However,  the association is not mobilized until the first broadcast or multicast message is actually received.</p>
579c2daa00SOllivier Robert<h4 id="many">Manycast and Pool Modes</h4>
589c2daa00SOllivier Robert<p>Manycast and pool modes are automatic discovery and configuration paradigms new to NTPv4. 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 vicinity. The intended result is that each  client mobilizes ephemeral client associations with some number of the &quot;best&quot; of the nearby  servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="discover.html">Automatic Server Discovery Schemes</a> page.</p>
59<h4 id="poll">Poll Interval Management</h4>
60<p>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 determine the best poll interval. When <tt>ntpd</tt> starts, the interval is the default minimum 64 s. Under normal conditions when the clock discipline has stabilized, the interval increases in steps to the default maximum 1024 s. In addition, should a server become unreachable 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 <a href="poll.html">Poll Program</a> page.</p>
61<p>The default poll interval range is suitable for most conditions, but can be changed using options on the <a href="confopt.html">Server Commands and Options</a> and <a href="miscopt.html">Miscellaneous Options</a> 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 capture and correct. The capture range is 500 PPM with a 64-s interval 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.</p>
62<p>In the NTPv4 specification and reference implementation, the poll interval is expressed in log<sub>2</sub> units, properly called the <em>poll exponent.</em> It is constrained by the lower limit <tt>minpoll</tt> and upper limit <tt>maxpoll</tt> options of the <a href="confopt.html"><tt>server</tt></a> command. The limits default to 6 (64 s) and 10 (1024 s), respectively, which are appropriate for the vast majority of cases.</p>
63<p>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 <a href="warp.html">How NTP Works</a> page.</p>
64<p>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.</p>
65<ul>
66  <li>With fast, lightly loaded LANs and modern processors, the nominal Allan intercept is about 500 s. In these cases the expected errors can be further reduced using a poll exponent of 4 (16 s). In the case of the pulse-per-second (PPS) driver, this is the recommended value.</li>
67  <li>With symmetric modes the most stable behavior results when both peers are configured in symmetric active mode with matching poll intervals of 6 (64 s).</li>
68  <li>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.</li>
69</ul>
70<h4 id="burst">Burst Options</h4>
71<p>Occasionally it is necessary to send packets temporarily at intervals less than the poll interval. For instance, with the <tt>burst</tt> and <tt>iburst</tt> options of the <a href="confopt.html"><tt>server</tt></a> command, the poll program sends a burst of several packets at 2-s intervals. In either case the 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 <a href="poll.html">Poll Program</a> page.</p>
72<p>There are two burst options where a single poll event triggers a burst. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands, but not 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.</p>
73<p>The <tt>iburst</tt> option is useful where the system clock must be set quickly or when the network attachment requires an initial calling or training sequence, as in PPP or ISDN services. In general, this option is recommended for  <tt>server</tt> and <tt>pool</tt> commands. A burst is sent only when 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 <a href="clock.html">Clock State Machine</a> page for further details about the startup behavior.</p>
74<p>The <tt>burst</tt> option  is useful in cases of severe network
75  jitter or when the network attachment requires an initial calling or training
76  sequence. This option is recommended when the minimum poll exponent is  larger than 10 (1024 s). A burst is sent only when the server is reachable.  The number of packets in the burst is determined by the poll interval
77  so that the average interval  between packets (headway) is no less than the minimum poll interval for the association.</p>
78<hr>
79<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
80</body>
81</html>
82