[ntp:bk-ntp-dev-send] BitKeeper diffs

Harlan Stenn stenn at whimsy.udel.edu
Thu Oct 25 02:46:56 UTC 2007


#### ChangeSet ####
2007-10-24 22:43:04-04:00, stenn at whimsy.udel.edu 
  ntp_proto.c:
    Orphan mode and other protocol cleanup from Dave Mills
  manyopt.html, assoc.html:
    Documentation cleanup from Dave Mills
  ChangeLog:
    Documentation cleanup from Dave Mills
    Orphan mode and other protocol cleanup from Dave Mills

==== ChangeLog ====
2007-10-24 22:42:25-04:00, stenn at whimsy.udel.edu +2 -0
  Documentation cleanup from Dave Mills
  Orphan mode and other protocol cleanup from Dave Mills

--- 1.132/ChangeLog	2007-10-22 21:38:32 -04:00
+++ 1.133/ChangeLog	2007-10-24 22:42:25 -04:00
@@ -1,3 +1,5 @@
+* Orphan mode and other protocol cleanup from Dave Mills.
+* Documentation cleanup from Dave Mills.
 * [Bug 940] ntp-keygen uses -v.  Disallow it as a shortcut for --version.
 * more cleanup to ntp_lineeditlibs.m4.
 * Documentation updates from Dave Mills.

==== html/assoc.html ====
2007-10-24 22:40:23-04:00, stenn at whimsy.udel.edu +37 -38
  Documentation cleanup from Dave Mills

--- 1.23/html/assoc.html	2007-10-20 01:30:16 -04:00
+++ 1.24/html/assoc.html	2007-10-24 22:40:23 -04:00
@@ -13,7 +13,7 @@
 		<h3>Association Management</h3>
 		<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>
 		<p>Make sure who your friends are.</p>
-		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">19:43</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="307">Friday, October 19, 2007</csobj></p>
+		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">20:15</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="275">Tuesday, October 23, 2007</csobj></p>
 		<br clear="left">
 		<h4>Related Links</h4>
 		<script type="text/javascript" language="javascript" src="scripts/links7.txt"></script>
@@ -22,54 +22,53 @@
 			<li class="inline"><a href="#modes">Association Modes</a>
 			<li class="inline"><a href="#client">Client/Server Mode</a>
 			<li class="inline"><a href="#symact">Symmetric Active/Passive Mode</a>
-			<li class="inline"><a href="#broad">Broadcast Mode</a>
-			<li class="inline"><a href="#mult">Multicast Mode</a>
+			<li class="inline"><a href="#broad">Broadcast/Multicast Modes</a>
 			<li class="inline"><a href="#many">Manycast Mode</a>
 			<li class="inline"><a href="#orphan">Orphan Mode</a>
-			<li class="inline"><a href="#burst">Burst Modes</a>
+			<li class="inline"><a href="#burst">Burst Options</a>
 		</ul>
 		<hr>
 		<h4 id="modes">Association Modes</h4>
-		<p>This page describes the various modes of operation provided in NTPv4.  Details about the configuration commands and options are described on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are described on the <a href="authopt.html">Authentication Options</a> page. Details about the automatic server discovery schemes are described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. While this page outlines the main issues about authenitcaion and server discovery, the details are beyond the scope of the discussion on this page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.</p>
-		<p>There are three types of associations in NTP: persistent, preemptable and ephemeral. 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>prempt</tt> flag and are demobilized by timeout or error or when displaced by a &quot;better&quot; server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.</p>
+		<p>This page describes the various modes of operation provided in NTPv4.  Details about the configuration commands and options are described on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are described on the <a href="authopt.html">Authentication Options</a> page. Details about the automatic server discovery schemes are described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html"> NTP Project</a> page.</p>
+		<p>There are three types of associations in NTP: persistent, preemptable and ephemeral. 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>prempt</tt> option and are demobilized by timeout or error or when displaced by a &quot;better&quot; server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.</p>
 		<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 in the <a href="authopt.html">Authentication Options</a> page.</p>
-		<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, manycast and pool described on the <a href="manyopt.html">Automatic Server Discovery Schemes</a> page. In addition, the orphan and burst modes described on this page can be used in appropriate cases. Following is a summary of the operations in each mode.</p>
+		<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="manyopt.html">Automatic Server Discovery Schemes</a> page. In addition, the orphan mode and burst options described on this page can be used in appropriate cases.</p>
+		<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">Configuration Options</a> page. See that page for applicability and defaults.</p>
 		<h4 id="client">Client/Server Mode</h4>
-		<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 client 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 client pulls the time and related values from the server.</p>
-		<p>A client is configured in client mode using the <tt>server</tt> (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration. The <tt>iburst</tt>&nbsp;mode described later on this page is recommended for use by clients, as this speeds up initial synchronization from several minutes to several seconds. The <tt>burst</tt>&nbsp;mode described later on this page is useful to improve jitter on very noisy dial-up or ISDN&nbsp;network links. This mode should always be used when the maximum expected poll interval is above 1024 s.</p>
+		<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>
+		<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 use by 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>
+		<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>
 		<h4 id="symact">Symmetric Active/Passive Mode</h4>
-		<p>Symmetric active/passive mode is intended for configurations were 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 radio clock, or a subset of secondary servers known to be 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 the others in the clique. In some contexts this would be described as a &quot;push-pull&quot; operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.</p>
-		<p>In symmetric mode a persistent peer sends a symmetric active (mode 1) message to a specified peer. If a matching persistent association is available, the peer returns a symetric active message as well. If no matchine association is avaialable, the peer mobilizes a ephemeral associaition and returnes a symmetric passive (mode) message.  Since an intruder can impersonate a symmetric active peer and inject false time values, symmetric mode should always be cryptographically validated.</p>
-		<p>A peer is configured in symmetric active mode using the <tt>peer</tt> command and specifying the other peer DNS&nbsp;name or IPv4 or IPv6 address. The <tt>burst</tt>&nbsp;and <tt>iburst</tt>&nbsp;modes 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. In symmetric cliques it is generally best to set the maximum poll interval of each member to the same value.</p>
-		<h4 id="broad">Broadcast Mode</h4>
-		<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 is supported with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast mode does not operate beyond a level-3 router. Where service is intended beyond a level-3 router, the multicast mode described in the next section can be used.</p>
-		<p>A server is configured in broadcast mode using the <tt>broadcast</tt> command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a <tt>broadcast</tt> command is needed for each address. This provides a way to limit exposure in a firewall, for example.</p>
-		<p>A broadcast client is configured using the <tt>broadcastclient</tt> command. While a broadcast message can be received on any interface, the <tt>restrict</tt> command described on the Access Control Options can be used to filter out unwanted addresses. Since an intruder can impersonate a broadcast or multicast server and inject false time values, broadcast mode should always be cryptographically authenticated.</p>
-		<p>In operation a broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overriden by the <tt>minpoll</tt> and <tt>ttl</tt> commands, respectively. Not all kernels support the  <tt>ttl</tt> command.</p>
-		<p>A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. The client then polls the server in client/server and iburst modes in order to quickly authenticate the server, set the host clock and calibrate the broadcast message propagation delay. This normally results in a volley of eight client/server exchanges at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently.</p>
-		<p>Following the volley, the server continues in listen-only mode and sends no further messages. If for some reason the broadcast server does not respond to client messages, the client will time out and continue in listen-only mode with a default propagation delay.</p>
-		<h4 id="mult">Multicast Mode</h4>
-		<p>NTP&nbsp;multicast mode can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A general discussion of IP multicast technology is beyond the scope of this page. In simple terms a host or router sending to a multicast group address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa.</p>
-		<p>The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6  address FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
-		<p>A multicast server is configured using the <tt>broadcast</tt> command, but specifying a multicast address instead of a broadcast address. A multicast client is configured using the <tt>multicastclient</tt> command specifying a list of one or more multicast addresses. Note that there is a subtle distinction  between the IPv4 and IPv6 address families. The IPv4 broadcast or mulitcast mode is determined by the IPv4 class. For IPv6 the same distinction can be made using the link-local prefix FF02 for each interface and site-local prefix FF05 for all interfacesl.</p>
-		<p>By design, multicast messages travel from the sender via a shortest-path or shared spanning tree to the receivers, which may require these messages emit from one or more local interfaces. It is possible to configure multiple multicast groups using multiple <tt>broadcast</tt> or <tt>multicastclient</tt> commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.</p>
+		<p>Symmetric active/passive mode is intended for configurations were 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 radio clock, or a set of secondary (stratu, 2) servers known to be 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 &quot;push-pull&quot; operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.</p>
+		<p>A peer with a configured symmetric active association 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>
+		<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>
+		<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>
+		<h4 id="broad">Broadcast/Multicast Modes</h4>
+		<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="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
 		<h4 id="many">Manycast Mode</h4>
-		<p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast 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 manycast client mobilizes client associations with some number of the &quot;best&quot; of the nearby anycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
-		<p>The <tt>manycastclient</tt> command specifies that the host is to operate in client mode with the remote servers that are discovered as the result of broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified <i><tt>address</tt></i> and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the <tt>server </tt>command. The remaining servers are discarded as if never heard.</p>
+		<p>Manycast mode is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a multicast client to troll the nearby network neighborhood to find cooperating manycast 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 manycast client mobilizes client associations with some number of the &quot;best&quot; of the nearby manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the <a href="manyopt.html">Automatic NTP Configuration Options</a> page.</p>
 		<h4 id="orphan">Orphan Mode</h4>
-		<p>Sometimes an NTP&nbsp;subnet becomes isolated from all UTC&nbsp;sources such as a local reference clock or Internet time server. In such cases it may be necessary that the subnet servers and clients remain synchronized to a common timescale, not necessarily the UTC&nbsp;timescale. Previously, this function was provided by the local clock driver to  simulate a UTC&nbsp;source. A server with this driver could be used to syunchronize other hosts in the subnet directly or indirectly.</p>
-		<p>There are many disadvantages using the local clock driver, primarily that the subnet is vulnerable to single-point failures and multiple server  redundancy is not possible. Orphan mode is intended to replace the local clock driver. It provides a single simulated UTC&nbsp;source with multiple servers and provides seamless switching as servers fail and recover.</p>
-		<p>A common configuration for private networks that might become isolated from UTC&nbsp;sources is to operate one or more core servers at the same lowest stratum to synchronize other hosts in the&nbsp;subnet. Good practice is to configure each core server as backup for the others using symmetric or broadcast modes. As long as at least one core server can reach a UTC&nbsp;source, the entire subnet can synchronize to it. However, if no UTC source is available, one of the core servers can provide a simulated UTC source for all other hosts in the subnet. However, only one core server can simulate the UTC&nbsp;source and all direct dependents must select the same one, called the orphan parent.</p>
-		<p>A host is enabled for orphan mode using the <tt>tos orphan <i>stratum</i></tt> command, where <tt><i>stratum</i></tt> is some stratum less than 16 and greater than any anticipated stratum that might occur with configured Internet time servers. However, sufficient headroom should remain so every subnet host dependent on the orphan parent has stratum less than 16. These are the same consideration that guides the local clock driver stratum selection.</p>
-		<p>A server with no sources and operating at the orphan stratum shows offset zero, root dispersion zero and reference ID&nbsp;127.0.0.1, (Unix loopback address. While primary (stratum 1)&nbsp;servers ordinarily show root delay zero, orphan servers show a value randomized when the association is mobilized. The orphan children; that is, those hosts operating at the orphan stratum plus one, chose the orphan parent as the orphan server with the smallest value.</p>
-		<p>For orphan mode to work well, each core server with available sources should operate at the same stratum, although the scheme works when they are not. Each potential orphan parent and each orphan child should include the same tos command in the configuration file. Each orphan child should include in the configuration file all root servers.</p>
-		<p>For example, consider a configuration where several campus secondary (stratum 2) servers are configured to use public Internet primary servers and with each other using symmetric or broadcast modes. For symmetric mode each core server is configured in symmetic-active mode with each other core server. For broadcast mode each core server is configured in both broadcast server and broadcast client modes. Orphan children operate in any mode with all core servers. Only the core servers and potential orphan children need to be enabled for orphan mode.</p>
-		<p>In normal operation subnet hosts operate below stratum 5, so the subnet is automatically configured as described in the NTP&nbsp;specification. If all UTC&nbsp;sources are lost, all core servers become orphans and the orphan children will select the same core server to become the orphan parent.</p>
-		<h4 id="burst">Burst Modes</h4>
-		<p>There are two burst modes where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal one packet. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands and not with reference clock drivers. The <tt>burst</tt> keyword sends a burst when the server is reachable, while the <tt>iburst</tt> keyword sends a burst when the server is unreachable. Each mode is independently of the other and both can be used at the same time. The <tt>calldelay</tt> command can be used to increase the interval between the first and second packets of the burst. This may be useful  to allow a modem to complete a call.</p>
+		<p>Sometimes an NTP subnet becomes isolated from all UTC sources such as local reference clocks or Internet time servers. In such cases it may be necessary that the subnet servers and clients remain synchronized to a common timescale, not necessarily the UTC timescale. Previously, this function was provided by the local clock driver to simulate a UTC source. A server with this driver could be used to synchronize other hosts in the subnet directly or indirectly.</p>
+		<p>There are many disadvantages using the local clock driver, primarily that the subnet is vulnerable to single-point failures and multiple server  redundancy is not possible. Orphan mode is intended to replace the local clock driver. It provides a single simulated UTC source with multiple servers and provides seamless switching as servers fail and recover.</p>
+		<p>A common configuration for private networks includes one or more core servers operating at the lowest stratum. Good practice is to configure each of these servers as backup for the others using symmetric or broadcast modes. As long as at least one core server can reach a UTC source, the entire subnet can synchronize to it. If no UTC source is available to a core server, it will synchronize to the others via the backup paths. The main reason for doing this is to minimize the transient when a UTC source again becomes available.</p>
+		<p>If no UTC sources are available to any core server, one of them can provide a simulated UTC source for all other hosts in the subnet. However, only one core server can simulate the UTC source and all direct dependents, called orphan children, must select the same one, called the orphan parent.</p>
+		<p>A host is enabled for orphan mode using the <tt>tos orphan <i>stratum</i></tt> command, where <tt><i>stratum</i></tt> is some stratum less than 16 and greater than any anticipated stratum that might occur with configured Internet time servers. However, sufficient headroom should remain so every subnet host dependent on the orphan children has stratum less than 16. These are the same consideration that guides the local clock driver stratum selection.</p>
+		<p>A root server with no sources and operating at the orphan stratum shows offset zero and reference ID 27.0.0.1 (Unix loopback address). While ordinary NTP clients use a selection metric based on delay and dispersion, orphan children use a metric computed from the IP address of each core server. Each orphan child chooses the orphan parent as the root server with the smallest value.</p>
+		<p>For orphan mode to work well, each core server with available sources should operate at the same stratum, although the scheme works when they are not. All core servers and orphan children should include the same tos command in the configuration file. Each orphan child should include in the configuration file all root servers.</p>
+		<div align-"center">
+				<img src="pic/peer.gif" alt="gif">
+		</div>
+		<p>For example, consider the peer network configuration above, where two or more campus primary or secondary (stratum 2) servers are configured with reference clocks or public Internet primary servers and with each other using symmetric modes. With this configuration a server that loses all sources continues to discipline the system clock using the other servers as backup. Only the core servers and orphan children need to be enabled for orphan mode.</p>
+		<div align-"center">
+			<img src="pic/broad.gif" alt="gif">
+		</div>
+		<p>For broadcast networks each core server is configured in both broadcast server and broadcast client modes as shown above. Orphan children operate as broadcast clients of all core servers. As in peer networks, the core servers back up each other and only they and the orphan children need to be enabled for orphan mode.</p>
+		<p>In normal operation subnet hosts operate below stratum 5, so the subnet is automatically configured as described in the NTP specification. If all UTC sources are lost, all core servers become orphans and the orphan children will select the same root server to become the orphan parent.</p>
+		<h4 id="burst">Burst Options</h4>
+		<p>There are two burst options where a single poll event triggers a burst of eight packets at 2-s intervals instead of the normal one packet. They should be used only with the <tt>server</tt> and <tt>pool</tt> commands and not with reference clock drivers. The <tt>burst</tt> option sends a burst when the server is reachable, while the <tt>iburst</tt> option sends a burst when the server is unreachable. Each mode is independently of the other and both can be used at the same time. The <tt>calldelay</tt> command can be used to increase the interval between the first and second packets of the burst. This may be useful  to allow a modem to complete a call.</p>
 		<p>In both modes received server packets update the clock filter, which select 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>
-		<p>The <tt>iburst</tt> mode is useful where the system clock must be set quickly or when the network attachment requires an initial calling or training sequence. The burst is initiated only when the server first becomes reachable. This improves accuracy with intermittent connections typical of PPP and ISDN services. Outlyers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first received packet.</p>
-		<p>The <tt>burst</tt> mode can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training sequence. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. In general, It should only be used where the minimum poll interval is 10 (1024 s) or greater.</p>
+		<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. The burst is initiated only when the server first becomes reachable. This improves accuracy with intermittent connections typical of PPP and ISDN services. Outliers due to initial dial-up delays, etc., are avoided and the client sets the clock within a few seconds after the first received packet.</p>
+		<p>The <tt>burst</tt> option can be configured in cases of excessive network jitter or when the network attachment requires an initial calling or training sequence. The burst is initiated at each poll interval when the server is reachable. The burst does produce additional network overhead and can cause trouble if used indiscriminately. In general, It should only be used where the minimum poll interval is 10 (1024 s) or greater.</p>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
 	</body>

==== html/manyopt.html ====
2007-10-24 22:40:27-04:00, stenn at whimsy.udel.edu +23 -7
  Documentation cleanup from Dave Mills

--- 1.14/html/manyopt.html	2007-10-20 01:30:20 -04:00
+++ 1.15/html/manyopt.html	2007-10-24 22:40:27 -04:00
@@ -13,24 +13,40 @@
 		<h3>Automatic Server Discovery Schemes</h3>
 		<img src="pic/alice51.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Alice's Adventures in Wonderland</i>, Lewis Carroll</a>
 		<p>Make sure who your friends are.</p>
-		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">05:12</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="270">Wednesday, October 17, 2007</csobj></p>
+		<p>Last update: <csobj format="ShortTime" h="25" locale="00000409" region="0" t="DateTime" w="61">21:27</csobj> UTC <csobj format="LongDate" h="25" locale="00000409" region="0" t="DateTime" w="275">Tuesday, October 23, 2007</csobj></p>
 		<br clear="left">
 		<h4>Related Links</h4>
 		<script type="text/javascript" language="javascript" src="scripts/links9.txt"></script>
 		<h4>Table of Contents</h4>
 		<ul>
-			<li class="inline"><a href="#bcst">Broadcasting</a>
-			<li class="inline"><a href="#mcst">Manycasting</a>
-			<li class="inline"><a href="#poolt">Pooling</a>
+			<li class="inline"><a href="#bcst">Broadcast/Multicast Scheme</a>
+			<li class="inline"><a href="#mcst">Manycast Scheme</a>
+			<li class="inline"><a href="#poolt">Server Pool Scheme</a>
 		</ul>
 		<hr>
-		<h4 id="bcst">Broadcasting</h4>
+		<h4 id="modes">Introduction</h4>
+		<p>This page describes the automatic server discovery schemes provided in NTPv4. Details about the configuration commands and options are described on the <a href="confopt.html">Configuration Options</a> page. Details about the cryptographic authentication schemes are described on the <a href="authopt.html">Authentication Options</a> page. Details about the other modes not directly involved in these schemes are described on the <a href="assocopt.html">Association Management</a> page. Additional information is available in the papers, reports, memoranda and briefings on the <a href="http://www.eecis.udel.edu/~mills/ntp.html">NTP Project</a> page.</p>
+		<p>There are three types of associations in NTP: persistent, preemptable and ephemeral. 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>prempt</tt> option and are demobilized by timeout or error or when displaced by a &quot;better&quot; server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.</p>
+		<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 in the <a href="authopt.html">Authentication Options</a> page.</p>
+		<p>There are three automatic server discovery schemes in NTP: broadcast/multicast, manycast and server pool described on this page. The broadcast/multicast and manycast schemes utilize the ubiquitous broadcast or one-to-many paradigm native to IPv4 and IPv6. The server pool scheme uses DNS to resolve multiple addresses of volunteer servers scattered throughout the world. </p>
+		<p>Following is a summary of the operations of each scheme. Note that reference to option applies to the commands described on the <a href="confopt.html">Configuration Options</a> page. See that page for applicability and defaults.</p>
+		<h4 id="bcst">Broadcast/Multicast Scheme</h4>
+		<p>In operation a broadcast server generates messages continuously at intervals by default 64 s and time-to-live by default 127. These defaults can be overriden by the <tt>minpoll</tt> and <tt>ttl</tt> options, respectively. Not all kernels support the <tt>ttl</tt> command.</p>
+		<p>A broadcast client responds to the first message received by waiting a randomized interval to avoid implosion at the server. The client then polls the server in client/server and iburst modes in order to quickly authenticate the server, set the host clock and calibrate the broadcast message propagation delay. This normally results in a volley of eight client/server exchanges at 2-s intervals during which both the synchronization and cryptographic protocols run concurrently.</p>
+		<p>Following the volley, the server continues in listen-only mode and sends no further messages. If for some reason the broadcast server does not respond to client messages, the client will time out and continue in listen-only mode with a default propagation delay.</p>
+		<p>A server is configured in broadcast mode using the <tt>broadcast</tt> command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a <tt>broadcast</tt> command is needed for each address. This provides a way to limit exposure in a firewall, for example.</p>
+		<p>A broadcast client is configured using the <tt>broadcastclient</tt> command. While a broadcast message can be received on any interface, the <tt>restrict</tt> command described on the Access Control Options can be used to filter out unwanted addresses. Since an intruder can impersonate a broadcast or multicast server and inject false time values, broadcast mode should always be cryptographically authenticated.</p>
+		<h4 id="mult">Multicast Mode</h4>
+		<p>NTP multicast mode can be used to extend the scope of a timekeeping subnet in two ways: multicasting and manycasting. A general discussion of IP multicast technology is beyond the scope of this page. In simple terms a host or router sending to a multicast group address expects all hosts or routers listening on this address to receive the message. There is no intrinsic limit on the number of senders or receivers and senders can be receivers and vice versa.</p>
+		<p>The IANA has assigned IPv4 multicast address 224.0.1.1 and IPv6 address FF05::101 (site local) to NTP, but these addresses should be used only where the multicast span can be reliably constrained to protect neighbor networks. In general, administratively scoped IPv4 group addresses should be used, as described in RFC-2365, or GLOP group addresses, as described in RFC-2770.</p>
+		<p>A multicast server is configured using the <tt>broadcast</tt> command, but specifying a multicast address instead of a broadcast address. A multicast client is configured using the <tt>multicastclient</tt> command specifying a list of one or more multicast addresses. Note that there is a subtle distinction between the IPv4 and IPv6 address families. The IPv4 broadcast or mulitcast mode is determined by the IPv4 class. For IPv6 the same distinction can be made using the link-local prefix FF02 for each interface and site-local prefix FF05 for all interfacesl.</p>
+		<p>By design, multicast messages travel from the sender via a shortest-path or shared spanning tree to the receivers, which may require these messages emit from one or more local interfaces. It is possible to configure multiple multicast groups using multiple <tt>broadcast</tt> or <tt>multicastclient</tt> commands. Other than these particulars, multicast messages are processed just like broadcast messages. Note that the calibration feature in broadcast mode is extremely important, since IP multicast messages can travel far different paths through the IP routing fabric than ordinary IP unicast messages.</p>
 		<p>Broadcasting is the simplest way to provide automatic server discovery. It uses the multi-destination paradigm, where the subnet spanning tree is constructed automatically, either by the switches in an Ethernet LAN&nbsp;or the DVMRP&nbsp;or PIM&nbsp;protocols when spanning multiple networks.</p>
 		<p>A broadcast or multicast server is mobilized by the broadcast configuration command. The addresses can be either from the IPv4 broadcast/mulitcast address family or the IPv6 address family. Multiple broadcast server associations can be specified for a single host.</p>
 		<p>A host is enabled for broadcast reception using the <tt>broadcastclient</tt> configuration command, with or without the <tt>novolley</tt> option. Upon receiving the first message from a broadcast server, the client mobilizes an ephemeral client association and exchanges a volley of client/server messages in order to quickly authenticate the source, set the clock and measure the propagation delay, then reverts to listen-only mode. A multicast client is mobilized in the same way using the <tt>multicastclient</tt> configuration command and specified multicast group address.</p>
 		<p>Broadcasting can be used with either symmetric key or public key cryptography. Public key cryptography offers the best protection against compromised keys and is generally considered stronger. By default, either of these two means is required, but this can be overridden by the <tt>disable auth</tt> command.</p>
 		<p>In both broadcast and multicast client operations the client association is demobilized in case of error or timeout due to loss of server or connectivity. </p>
-		<h4 id="mcst">Manycasting</h4>
+		<h4 id="mcst">Manycast Scheme</h4>
 		<p>Manycasting is a automatic discovery and configuration paradigm new to NTPv4. It is intended as a means for a client to troll the nearby network neighborhood to find cooperating 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 associations with a given number of the &quot;best&quot; nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail.</p>
 		<p>Note that the manycast paradigm does not coincide with the anycast paradigm described in RFC-1546, which is designed to find a single server from a clique of servers providing the same service. The manycast paradigm is designed to find a plurality of redundant servers satisfying defined optimality criteria.</p>
 		<p>Manycasting can be used with either symmetric key or public key cryptography. Public key cryptography offers the best protection against compromised keys and is generally considered stronger. By default, either of these two means is required, but this can be overridden by the <tt>disable auth</tt> command.</p>
@@ -42,7 +58,7 @@
 		<p>For example, consider an NTP subnet of two primary servers and several secondary servers and a number of dependent clients. With twoAll servers and clients have identical configuration files including both <tt>multicastclient</tt> and <tt>multicastserver</tt> commands using, for instance, multicast group address 239.1.1.1. Each primary server configuration file must include commands for the primary reference source such as a GPS receiver.</p>
 		<p>The remaining configuration files for all secondary servers and clients have the same contents, except for the <tt>tos</tt> command, which is specific for each stratum level. For stratum 1 and stratum 2 servers, that command is not necessary. For stratum 3 and above servers the <tt>tos floor</tt> value is set to the intended stratum number. Thus, all stratum 3 configuration files use <tt>tos floor 3</tt>, all stratum 4 files use <tt>tos floor 4</tt> and so forth.</p>
 		<p>Once operations have stabilized, the primary servers will find the primary reference source and each other, since they both operate at the same stratum (1), but not with any secondary server or client, since these operate at a higher stratum. The secondary servers will find the servers at the same stratum level. If one of the primary servers loses its GPS receiver, it will continue to operate as a client and other clients will time out the corresponding association and re-associate accordingly.</p>
-		<h4 id="pool"> Pooling</h4>
+		<h4 id="pool">Server Pool Scheme</h4>
 		<p>bibbidt</p>
 		<hr>
 		<script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>

==== ntpd/ntp_proto.c ====
2007-10-24 22:41:50-04:00, stenn at whimsy.udel.edu +43 -68
  Orphan mode and other protocol cleanup from Dave Mills

--- 1.263/ntpd/ntp_proto.c	2007-10-18 01:52:05 -04:00
+++ 1.264/ntpd/ntp_proto.c	2007-10-24 22:41:50 -04:00
@@ -90,7 +90,6 @@ int	sys_minclock = NTP_MINCLOCK; /* mini
 int	sys_maxclock = NTP_MAXCLOCK; /* maximum candidates */
 int	sys_cohort = 0;		/* cohort switch */
 int	sys_orphan = STRATUM_UNSPEC + 1; /* orphan stratum */
-double	sys_orphandelay = 0;	/* orphan root delay */
 int	sys_beacon = BEACON;	/* manycast beacon interval */
 int	sys_ttlmax;		/* max ttl mapping vector index */
 u_char	sys_ttl[MAX_TTL];	/* ttl mapping vector */
@@ -137,20 +136,16 @@ transmit(
 	 */
 	/*
 	 * Orphan mode is active when enabled and when no servers less
-	 * than the orphan statum are available. In this mode packets
-	 * are sent at the orphan stratum. An orphan with no other
-	 * synchronization source is an orphan parent. It assumes root
-	 * delay zero and reference ID the loopback address. All others
-	 * are orphan children with root delay randomized over a 1-s
-	 * range. The root delay is used by the election algorithm to
-	 * select the order of synchronization.
+	 * than the orphan statum are available. A server with no other
+	 * synchronization source is an orphan It shows offset zero and
+	 * reference ID the loopback address.
 	 */
 	hpoll = peer->hpoll;
 	if (sys_orphan < STRATUM_UNSPEC && sys_peer == NULL) {
 		sys_leap = LEAP_NOWARNING;
 		sys_stratum = sys_orphan;
 		sys_refid = htonl(LOOPBACKADR);
-		sys_rootdelay = sys_orphandelay;
+		sys_rootdelay = 0;
 		sys_rootdisp = sys_mindisp;
 		sys_offset = 0;
 	}
@@ -702,19 +697,12 @@ receive(
 		}
 
 		/*
-		 * Do not respond if unsynchronized or stratum is below
-		 * the floor or at or above the ceiling.
-		 */
-		if (sys_leap == LEAP_NOTINSYNC || sys_stratum <
-		    sys_floor || sys_stratum >= sys_ceiling)
-			return;			/* bad stratum */
-
-		/*
-		 * Do not respond if our stratum is greater than the
-		 * manycaster or it has already synchronized to us.
+		 * Do not respond if we have no system peer or our
+		 * stratum is greater than the manycaster or the
+		 * manycaster has already synchronized to us.
 		 */
-		if (sys_peer == NULL || hisstratum < sys_stratum ||
-		    (sys_cohort && hisstratum == sys_stratum) ||
+		if (sys_peer == NULL || sys_stratum >= hisstratum ||
+		    (!sys_cohort && sys_stratum == hisstratum + 1) ||
 		    rbufp->dstadr->addr_refid == pkt->refid)
 			return;			/* no help */
 
@@ -750,6 +738,14 @@ receive(
 		    (RES_NOPEER | RES_DONTTRUST)), is_authentic))
 			return;			/* bad auth */
 
+		/*
+		 * Do not respond if unsynchronized or stratum is below
+		 * the floor or at or above the ceiling.
+		 */
+		if (hisleap == LEAP_NOTINSYNC || hisstratum <
+		    sys_floor || hisstratum >= sys_ceiling)
+			return;			/* bad stratum */
+
 		if ((peer2 = findmanycastpeer(rbufp)) == NULL) {
 			sys_restricted++;
 			return;			/* not enabled */
@@ -790,6 +786,15 @@ receive(
 		    sys_floor || hisstratum >= sys_ceiling)
 			return;			/* bad stratum */
 
+		/*
+		 * Do not respond if we have a system peer and our
+		 * stratum is not greater than the broadcaster or the
+		 * broadcaster has already synchronized to us.
+		 */
+		if ((sys_peer != NULL && sys_stratum <= hisstratum) ||
+		    rbufp->dstadr->addr_refid == pkt->refid)
+			return;			/* no help */
+
 		switch (sys_bclient) {
 
 		/*
@@ -1423,19 +1428,7 @@ clock_update(
 			report_event(EVNT_SYNCCHG, NULL);
 		}
 		sys_stratum = min(peer->stratum + 1, STRATUM_UNSPEC);
-
-		/*
-		 * In orphan mode the stratum is clamped to the orphan
-		 * stratum and the root delay is set to a random value
-		 * generated at startup. Otherwise, the root delay is
-		 * set to the peer delay plus the peer root delay.
-		 */
-		if (sys_stratum >= sys_orphan) {
-			sys_stratum = sys_orphan;
-			sys_rootdelay = sys_orphandelay;
-		} else {
-			sys_rootdelay = peer->delay + peer->rootdelay;
-		}
+		sys_rootdelay = peer->delay + peer->rootdelay;
 		sys_reftime = peer->rec;
 
 		/*
@@ -2154,16 +2147,13 @@ clock_select(void)
 	 * NTP_MAXASSOC of them. Scan the list to find falsetickers, who
 	 * leave the island immediately. The TRUE peer is always a
 	 * truechimer. We must leave at least one peer to collect the
-	 * million bucks. If in orphan mode, rascals found with lower
-	 * stratum are guaranteed a seat on the bus.
+	 * million bucks.
 	 */
 	j = 0;
 	for (i = 0; i < nlist; i++) {
 		peer = peer_list[i];
 		if (nlist > 1 && (peer->offset <= low || peer->offset >=
-		    high) && !(peer->flags & FLAG_TRUE) &&
-		    !(sys_stratum >= sys_orphan && peer->stratum <
-		    sys_orphan))
+		    high) && !(peer->flags & FLAG_TRUE))
 			continue;
 
 		peer->status = CTL_PST_SEL_DISTSYSPEER;
@@ -2348,16 +2338,7 @@ clock_select(void)
 	 * the existing system peer, if any, and (5) the head of the
 	 * survivor list.
 	 */
-	if (typesystem->stratum >= sys_orphan) {
-
-		/*
-		 * If in orphan modeand the lowest distance, we are the
-		 * orphan parent otherwise, we are an orphan child.
-		 */
-		if (sys_orphandelay <= typesystem->rootdelay) {
-			sys_peer = NULL;
-			return;
-		}
+	if (typesystem->stratum == sys_orphan) {
 		sys_peer = typesystem;
 		sys_peer->status = CTL_PST_SEL_SYSPEER;
 		sys_offset = sys_peer->offset;
@@ -2481,19 +2462,18 @@ root_distance(
 	struct peer *peer	/* peer structure pointer */
 	)
 {
-	double ftemp;
 
 	/*
 	 * Careful squeak here. The value returned must be greater than
 	 * the minimum root dispersion in order to avoid clockhop with
-	 * highly precise reference clocks. In orphan mode use only the
-	 * peer root delay, as that is used by the mitigation algorithm.
+	 * highly precise reference clocks. In orphan mode use the peer
+	 * address to fool the mitigation algorithm.
 	 */
-	if (peer->stratum >= sys_orphan)
-		ftemp = 0;
-	else
-		ftemp = peer->rootdelay;
-	return ((peer->delay + ftemp) / 2 + peer->disp +
+	if (peer->stratum == sys_orphan)
+		return (addr2refid(&peer->srcadr) / FRAC * sys_maxdist /
+		    1.);
+
+	return ((peer->delay + peer->rootdelay) / 2 + peer->disp +
 	    peer->rootdisp + clock_phi * (current_time - peer->update) +
 	    peer->jitter);
 }
@@ -3095,13 +3075,10 @@ peer_unfit(
 	/*
 	 * A stratum error occurs if (1) the server has never been
 	 * synchronized, (2) the server stratum is below the floor or
-	 * greater than or equal to the ceiling, (3) the system stratum
-	 * is below the orphan stratum and the server stratum is greater
-	 * than or equal to the orphan stratum.
+	 * greater than or equal to the ceiling.
 	 */
 	if (peer->leap == LEAP_NOTINSYNC || peer->stratum < sys_floor ||
-	    peer->stratum >= sys_ceiling || (sys_stratum < sys_orphan &&
-	    peer->stratum >= sys_orphan))
+	    peer->stratum >= sys_ceiling)
 		rval |= TEST10;		/* stratum out of bounds */
 
 	/*
@@ -3116,12 +3093,12 @@ peer_unfit(
 	/*
 	 * A loop error occurs if the remote peer is synchronized to the
 	 * local peer of if the remote peer is synchronized to the same
-	 * server as the local peer, but only if the remote peer is not
-	 * the orphan parent.
+	 * server as the local peer but only if the remote peer is
+	 * neither a reference clock nor an orphan.
 	 */
 	if (peer->stratum > 1 && peer->refid != htonl(LOOPBACKADR) &&
-	    ((!peer->dstadr || peer->refid ==
-	    peer->dstadr->addr_refid) || peer->refid == sys_refid))
+	    (peer->refid == (peer->dstadr ? peer->dstadr->addr_refid :
+	    0) || peer->refid == sys_refid))
 		rval |= TEST12;		/* synch loop */
 
 	/*
@@ -3230,8 +3207,6 @@ init_proto(void)
 
 	memcpy(&sys_refid, "INIT", 4);
 	sys_precision = (s_char)default_get_precision();
-	sys_orphandelay = (double)(ntp_random() & 0xffff) / 65536. *
-	    sys_maxdist;
 	get_systime(&dummy);
 	sys_survivors = 0;
 	sys_manycastserver = 0;


More information about the bk-ntp-dev-send mailing list