Recall that an NTP client has an association for each remote server and local reference clock. There are three types of associations: persistent, preemptable, and ephemeral. Persistent associations are explicitly configured and mobilized at startup. Preemptable associations are mobilized at startup or as the result of a server discovery scheme described later. Ephemeral associations are mobilized by protocol operations described in this topic. Persistent associations are never demobilized, although they may become dormant when the associated server becomes unreachable. Preemptable associations are demobilized when discarded by the cluster algorithm. Ephemeral associations are demobilized after some interval when the server is no longer heard. Since an intruder can impersonate a server and inject false time values, ephemeral associations should always be cryptographically authenticated.
In the following, a careful distinction is made among server, client, and peer operations. A server provides synchronization to a client but never accepts it. A client accepts synchronization from a server but never provides it. On the other hand, peers operate in pairs; either peer can provide or accept synchronization from the other, depending on their other sources. What may be confusing is that a particular NTP host can operate with any combination of modes—server, client, and peer—depending on configuration. This provides flexibility in subnet design and fault confinement. A primary server is synchronized by external means, such as a GPS receiver, and accepts synchronization from no other source, while a secondary server accepts synchronization from another server and provides synchronization to other servers and clients.
The NTP specification includes a subset called the Simple Network Time Protocol (SNTP), which has the same on-wire packet format and protocol but not necessarily the full suite of NTP mitigation and grooming algorithms. For instance, a primary server can run SNTP because it does not accept synchronization, while a client can run SNTP because it does not provide synchronization. However, since a secondary server both accepts and provides synchronization, it is part of a cascaded chain of feedback loops that must have a controlled impulse response with specified rise time and overshoot. Therefore, a secondary server must conform to the full NTP specification.
There are three principal modes of operation: client/server, symmetric, and broadcast. These modes are selected based on the scope of service, intended flow of time values, and means of configuration. In all modes, the reference implementation supports both the traditional Internet Protocol Version 4 (IPv4) and its sixth version (IPv6) defined in Request for Comments (RFC) 3513 [1]. Ordinarily, the use of either IP version is transparent to the NTP time and security protocols with minor exceptions noted in the user documentation.
Client/server mode is probably the most common configuration in the Internet today. It operates in the classic remote procedure call (RPC) paradigm with stateless servers. In this mode, a client sends a request to the server and expects a reply at some future time. In some contexts, this would be described as a pull operation, in that the client pulls the time values from the server. In the reference implementation, a client specifies one or more persistent client associations in the configuration file by DNS (domain name system) name or IP address; the servers require no prior configuration.
Symmetric active/passive mode is intended for configurations in which a clique of low-stratum peers operates as mutual backups for each other. Each peer normally operates with one or more sources, such as a reference clock, or a subset of primary and secondary servers known to be reliable and authentic. Should one of the peers lose all reference clocks or simply cease operation, the other peers will automatically reconfigure so that time values can flow from the surviving peers to all the others in the subnet. In some contexts, this would be described as a push-pull operation, in that each peer either pulls or pushes the time values depending on the particular configuration and stratum.
Symmetric peers operate with their sources in some NTP mode and with each other in symmetric modes. In the reference implementation, a peer specifies one or more persistent symmetric active peer associations in the configuration file by DNS name or IP address. Other peers can also be configured in symmetric active mode; however, if a peer is not specifically configured, a symmetric passive association is mobilized on arrival of a message from a symmetric active peer.
Broadcast mode is intended for configurations involving one or a few servers and possibly a large client population. In the reference implementation, the configuration file specifies one or more persistent broadcast associations with subnet address or multicast group address, as appropriate. A broadcast client is declared in the configuration file with optional subnet address or group address. The Internet Assigned Numbers Authority (IANA) has assigned IPv4 multicast group address 224.0.1.1 to NTP, but this address should be used only when the span can be reliably constrained to protect neighbor networks. The IANA has assigned permanent IPv6 broadcast address 101 to NTP. This is ordinarily used with the site-local prefix ff05. Further explanation can be found in RFC-3513 [1].
The broadcast server generates messages continuously at intervals usually on the order of a minute. In some contexts, this would be described as a push operation, in that the server pushes the time values to configured clients. A broadcast client normally responds to the first message received after waiting an interval randomized to avoid implosion at the server. Then, the client polls the server in client/server mode using the burst feature (discussed further in this section) to reliably set the system clock and authenticate the source. This normally results in a volley of eight exchanges over a 16-s interval during which both the synchronization and the cryptographic authentication protocols run concurrently. When the volley is complete, the client sets the clock and computes the offset between the broadcast time and the client time. This offset is used to compensate for the propagation time between the broadcast server and client and is extremely important in the common cases when the unicast and broadcast messages travel far different paths through the IP routing fabric. Once the offset is computed, the server continues as before, and the client sends no further messages.
There are two new modes recently added to the NTPv4 reference implementation that can significantly reduce the effects of queuing and scheduling delays in the operating system.Briefly, the on-wire protocol is modified to put the output packet interrupt timestamp in the next following packet.
In the reference implementation, a burst feature can be enabled for each persistent client/server association separately. When enabled, a single poll initiates a burst of eight client messages at intervals of 2 s. The result is not only a rapid and reliable setting of the system clock but also a considerable reduction in network jitter. The burst feature can be enabled when the server is unreachable, reachable, or both. The unreachable case is intended when it is important to set the clock quickly when an association is first mobilized. The reachable case is intended when the network attachment requires an initial calling or training procedure for each poll and results in good accuracy with intermittent connections typical of Point-to-Point Protocol (PPP) and Integrated Services Digital Network (ISDN) services. The burst feature is useful also in cases of excessive network jitter or when the poll interval is exceptionally large, like over a day.
