From: Harlan Stenn Date: Thu, 25 Oct 2007 02:43:04 +0000 (-0400) Subject: ntp_proto.c: X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f416a5993983db9899508d7bd383d1124aebec13;p=thirdparty%2Fntp.git 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 bk: 472002b8nnl4gcaouhSzyQ-bts80jQ --- diff --git a/ChangeLog b/ChangeLog index ab21062cd6..b53a8d4fdd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -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. diff --git a/html/assoc.html b/html/assoc.html index 4b2937b5e7..78d32c2d57 100644 --- a/html/assoc.html +++ b/html/assoc.html @@ -13,7 +13,7 @@

Association Management

giffrom Alice's Adventures in Wonderland, Lewis Carroll

Make sure who your friends are.

-

Last update: 19:43 UTC Friday, October 19, 2007

+

Last update: 20:15 UTC Tuesday, October 23, 2007


Related Links

@@ -22,54 +22,53 @@
  • Association Modes
  • Client/Server Mode
  • Symmetric Active/Passive Mode -
  • Broadcast Mode -
  • Multicast Mode +
  • Broadcast/Multicast Modes
  • Manycast Mode
  • Orphan Mode -
  • Burst Modes +
  • Burst Options

    Association Modes

    -

    This page describes the various modes of operation provided in NTPv4. Details about the configuration commands and options are described on the Configuration Options page. Details about the cryptographic authentication schemes are described on the Authentication Options page. Details about the automatic server discovery schemes are described on the Automatic Server Discovery Schemes 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 NTP Project page.

    -

    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 prempt flag and are demobilized by timeout or error or when displaced by a "better" server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.

    +

    This page describes the various modes of operation provided in NTPv4. Details about the configuration commands and options are described on the Configuration Options page. Details about the cryptographic authentication schemes are described on the Authentication Options page. Details about the automatic server discovery schemes are described on the Automatic Server Discovery Schemes page. Additional information is available in the papers, reports, memoranda and briefings on the NTP Project page.

    +

    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 prempt option and are demobilized by timeout or error or when displaced by a "better" server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.

    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 Authentication Options page.

    -

    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 Automatic Server Discovery Schemes 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.

    +

    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 Automatic Server Discovery Schemes page. In addition, the orphan mode and burst options described on this page can be used in appropriate cases.

    +

    Following is a summary of the operations in each mode. Note that reference to option applies to the commands described on the Configuration Options page. See that page for applicability and defaults.

    Client/Server Mode

    -

    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 "pull" operation, in that the client pulls the time and related values from the server.

    -

    A client is configured in client mode using the server (sic) command and specifying the server IPv4 or IPv6 DNS name or address; the server requires no prior configuration. The iburst 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 burst mode described later on this page is useful to improve jitter on very noisy dial-up or ISDN network links. This mode should always be used when the maximum expected poll interval is above 1024 s.

    +

    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.

    +

    A host is configured in client mode using the server (sic) command and specifying the server DNS name or IPv4 or IPv6 address; the server requires no prior configuration. The iburst 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 burst 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 the default minimum and maximum values. The minpoll and maxpoll options can be used to bracket the range. Unless noted otherwise, these options should not be used with reference clock drivers.

    Symmetric Active/Passive Mode

    -

    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 "push-pull" operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.

    -

    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.

    -

    A peer is configured in symmetric active mode using the peer command and specifying the other peer DNS name or IPv4 or IPv6 address. The burst and iburst 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.

    -

    Broadcast Mode

    -

    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.

    -

    A server is configured in broadcast mode using the broadcast command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a broadcast command is needed for each address. This provides a way to limit exposure in a firewall, for example.

    -

    A broadcast client is configured using the broadcastclient command. While a broadcast message can be received on any interface, the restrict 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.

    -

    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 minpoll and ttl commands, respectively. Not all kernels support the ttl command.

    -

    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.

    -

    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.

    -

    Multicast Mode

    -

    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.

    -

    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.

    -

    A multicast server is configured using the broadcast command, but specifying a multicast address instead of a broadcast address. A multicast client is configured using the multicastclient 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.

    -

    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 broadcast or multicastclient 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.

    +

    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 "push-pull" operation, in that the peer either pulls or pushes the time and related values depending on the particular configuration.

    +

    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.

    +

    A peer is configured in symmetric active mode using the peer command and specifying the other peer DNS name or IPv4 or IPv6 address. The burst and iburst 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.

    +

    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 minpoll and maxpoll options.

    +

    Broadcast/Multicast Modes

    +

    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 Automatic NTP Configuration Options page.

    Manycast Mode

    -

    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 "best" of the nearby anycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the Automatic NTP Configuration Options page.

    -

    The manycastclient 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 address and specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the server command. The remaining servers are discarded as if never heard.

    +

    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 "best" of the nearby manycast servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the Automatic NTP Configuration Options page.

    Orphan Mode

    -

    Sometimes an NTP subnet becomes isolated from all UTC 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 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 syunchronize other hosts in the subnet directly or indirectly.

    -

    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.

    -

    A common configuration for private networks that might become isolated from UTC sources is to operate one or more core servers at the same lowest stratum to synchronize other hosts in the 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 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 source and all direct dependents must select the same one, called the orphan parent.

    -

    A host is enabled for orphan mode using the tos orphan stratum command, where stratum 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.

    -

    A server with no sources and operating at the orphan stratum shows offset zero, root dispersion zero and reference ID 127.0.0.1, (Unix loopback address. While primary (stratum 1) 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.

    -

    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.

    -

    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.

    -

    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 core server to become the orphan parent.

    -

    Burst Modes

    -

    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 server and pool commands and not with reference clock drivers. The burst keyword sends a burst when the server is reachable, while the iburst 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 calldelay 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.

    +

    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.

    +

    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.

    +

    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.

    +

    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.

    +

    A host is enabled for orphan mode using the tos orphan stratum command, where stratum 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.

    +

    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.

    +

    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.

    +
    + gif +
    +

    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.

    +
    + gif +
    +

    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.

    +

    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.

    +

    Burst Options

    +

    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 server and pool commands and not with reference clock drivers. The burst option sends a burst when the server is reachable, while the iburst 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 calldelay 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.

    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.

    -

    The iburst 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.

    -

    The burst 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.

    +

    The iburst 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.

    +

    The burst 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.

    diff --git a/html/manyopt.html b/html/manyopt.html index 03974d2ba2..f5235f9ed0 100644 --- a/html/manyopt.html +++ b/html/manyopt.html @@ -13,24 +13,40 @@

    Automatic Server Discovery Schemes

    giffrom Alice's Adventures in Wonderland, Lewis Carroll

    Make sure who your friends are.

    -

    Last update: 05:12 UTC Wednesday, October 17, 2007

    +

    Last update: 21:27 UTC Tuesday, October 23, 2007


    Related Links

    Table of Contents

    -

    Broadcasting

    +

    Introduction

    +

    This page describes the automatic server discovery schemes provided in NTPv4. Details about the configuration commands and options are described on the Configuration Options page. Details about the cryptographic authentication schemes are described on the Authentication Options page. Details about the other modes not directly involved in these schemes are described on the Association Management page. Additional information is available in the papers, reports, memoranda and briefings on the NTP Project page.

    +

    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 prempt option and are demobilized by timeout or error or when displaced by a "better" server. Ephemeral associations are mobilized upon arrival of designated messages and demobilized only by timeout or error.

    +

    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 Authentication Options page.

    +

    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.

    +

    Following is a summary of the operations of each scheme. Note that reference to option applies to the commands described on the Configuration Options page. See that page for applicability and defaults.

    +

    Broadcast/Multicast Scheme

    +

    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 minpoll and ttl options, respectively. Not all kernels support the ttl command.

    +

    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.

    +

    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.

    +

    A server is configured in broadcast mode using the broadcast command and specifying the broadcast address of a local interface. If two or more local interfaces are installed with different broadcast addresses, a broadcast command is needed for each address. This provides a way to limit exposure in a firewall, for example.

    +

    A broadcast client is configured using the broadcastclient command. While a broadcast message can be received on any interface, the restrict 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.

    +

    Multicast Mode

    +

    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.

    +

    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.

    +

    A multicast server is configured using the broadcast command, but specifying a multicast address instead of a broadcast address. A multicast client is configured using the multicastclient 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.

    +

    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 broadcast or multicastclient 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.

    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 or the DVMRP or PIM protocols when spanning multiple networks.

    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.

    A host is enabled for broadcast reception using the broadcastclient configuration command, with or without the novolley 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 multicastclient configuration command and specified multicast group address.

    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 disable auth command.

    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.

    -

    Manycasting

    +

    Manycast Scheme

    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 "best" nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail.

    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.

    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 disable auth command.

    @@ -42,7 +58,7 @@

    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 multicastclient and multicastserver 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.

    The remaining configuration files for all secondary servers and clients have the same contents, except for the tos 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 tos floor value is set to the intended stratum number. Thus, all stratum 3 configuration files use tos floor 3, all stratum 4 files use tos floor 4 and so forth.

    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.

    -

    Pooling

    +

    Server Pool Scheme

    bibbidt

    diff --git a/ntpd/ntp_proto.c b/ntpd/ntp_proto.c index 70c9c65b3c..d26ffc3321 100644 --- a/ntpd/ntp_proto.c +++ b/ntpd/ntp_proto.c @@ -90,7 +90,6 @@ int sys_minclock = NTP_MINCLOCK; /* minimum candidates */ 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;