NTP ( Network Time Protocol )

• NTP needs some reference clock that defines the true time to operate. All clocks are set towards that true time. (It will not just make all systems agree on some time, but will make them agree upon the true time as defined by some standard.)



• NTP is a fault-tolerant protocol that will automatically select the best of several available time sources to synchronize to. Multiple candidates can be combined to minimize the accumulated error. Temporarily or permanently insane time sources will be detected and avoided.



• NTP is highly scalable: A synchronization network may consist of several reference clocks. Each node of such a network can exchange time information either bidirectional or unidirectional. Propagating time from one node to another forms a hierarchical graph with reference clocks at the top.



• Having available several time sources, NTP can select the best candidates to build its estimate of the current time. The protocol is highly accurate, using a resolution of less than a nanosecond (about 2 - 32 seconds).



• Even when a network connection is temporarily unavailable, NTP can use measurements from the past to estimate current time and error.



• For formal reasons NTP will also maintain estimates for the accuracy of the local time.

Header format


2	5	8	16	24	32
LI	VN	Mode	Stratum	Poll	Precision
Root Delay
Root Dispersion
Reference Identifier
Reference timestamp (64)
Originate Timestamp (64)
Receive Timestamp (64)
Transmit Timestamp (64)
Key Identifier (optional) (32)
Message digest (optional) (128)



• LI Leap Indicator
  A 2-bit code warning of impending leap-second to be inserted at the end of the last day of the current month. Bits are coded as follows:



00	No warning.
01	+1 second (following minute has 61 seconds).
10	-1 second (following minute has 59 seconds).
11	Alarm condition (clock not synchronized).



• VN
  Version number 3 bit code indicating the version number.



• Mode
  The mode: This field can contain the following values:



0	Reserved.
1	Symmetric active.
3	Client.
4	Server.
5	Broadcast.
6	NTP control message.



• Stratum
  An integer identifying the stratum level of the local clock. Values are defined as follows:



0	Unspecified.
1	Primary reference (e.g. radio clock).
2...n	Secondary reference (via NTP).



• Poll
  Signed integer indicating the maximum interval between successive messages, in seconds to the nearest power of 2.



• Precision
  Signed integer indicating the precision of the local clock, in seconds to the nearest power of 2.



• Root Delay
  Signed fixed-point number indicating the total roundtrip delay to the primary reference source, in seconds with fraction point between bits 15 and 16.



• Root Dispersion
  Unsigned fixed-point number indicating the nominal error relative to the primary reference source, in seconds with fraction point between bits 15 and 16.



• Reference Identifier
  Identifying the particular reference source.



• Originate Timestamp
  This is the time at which the request departed the client for the server, in 64-bit timestamp format.



• Receive Timestamp
  This is the time at which the request arrived at the server, in 64-bit timestamp format.



• Transmit Timestamp
  This is the time at which the reply departed the server for the client, in 64-bit timestamp format.



• Authenticator (optional)
  When the NTP authentication scheme is implemented, the Key Identifier and Message Digest fields contain the message authentication code (MAC) information defined.

• Symmetric Active
  A host operating in this mode sends periodic messages regardless of the reachability state or stratum of its peer. By operating in this mode the host announces its willingness to synchronize and be synchronized by the peer.



• Symmetric Passive
  This type of association is ordinarily created upon arrival of a message from a peer operating in the symmetric active mode and persists only as long as the peer is reachable and operating at a stratum level less than or equal to the host; otherwise, the association is dissolved. However, the association will always persist until at least one message has been sent in reply. By operating in this mode the host announces its willingness to synchronize and be synchronized by the peer.



• Client
  A host operating in this mode sends periodic messages regardless of the reachability state or stratum of its peer. By operating in this mode the host, usually a LAN workstation, announces its willingness to be synchronized by, but not to synchronize the peer.



• Server
  This type of association is ordinarily created upon arrival of a client request message and exists only in order to reply to that request, after which the association is dissolved. By operating in this mode the host, usually a LAN time server, announces its willingness to synchronize, but not to be synchronized by the peer.



• Broadcast
  A host operating in this mode sends periodic messages regardless of the reachability state or stratum of the peers. By operating in this mode the host, usually a LAN time server operating on a high-speed broadcast medium, announces its willingness to synchronize all of the peers, but not to be synchronized by any of them.

• Notation Conventions
  The NTP filtering and selection algorithms act upon a set of variables for clock offset (<$Etheta ,~THETA>), roundtrip delay (<$Edelta ,~DELTA>) and dispersion (<$Eepsilon ,~EPSILON>).



• Transmit Procedure
  The transmit procedure is executed when the peer timer decrements to zero for all modes except client mode with a broadcast server and server mode in all cases. In client mode with a broadcast server messages are never sent. In server mode messages are sent only in response to received messages. This procedure is also called by the receive procedure when an NTP message arrives that does not result in a persistent association.



• Receive Procedure
  The receive procedure is executed upon arrival of an NTP message. It validates the message, interprets the various modes and calls other procedures to filter the data and select the synchronization source. If the version number in the packet does not match the current version, the message may be discarded; however, exceptions may be advised on a case- by-case basis at times when the version is changed.



• Packet Procedure
  The packet procedure checks the message validity, computes delay/offset samples and calls other procedures to filter the data and select the synchronization source.



• Clock-Update Procedure
  The clock-update procedure is called from the receive procedure when valid clock offset, delay and dispersion data have been determined by the clock-filter procedure for the current peer.



• Primary-Clock Procedure
  When a primary reference source such as a radio clock is connected to the host, it is convenient to incorporate its information into the data base as if the clock were represented as an ordinary peer.



• Clear Procedure
  The clear procedure is called when some event occurs that results in a significant change in reachability state or potential disruption of the local clock.



• Poll-Update Procedure
  The poll-update procedure is called when a significant event occurs that may result in a change of the poll interval or peer timer.

Example 1: Notation Conventions



Each time the relevant peer variables are updated, all dispersions associated with that 

peer are updated to reflect the skew-error accumulation. The computations can be 

summarized as follows:



       <$Etheta~==~roman peer.offset>,

       <$Edelta~==~roman peer.delay>,

       <$Eepsilon~==~roman peer.dispersion~=~rho~+~phi tau~+~epsilon sub sigma>,

       <$Elambda~==~epsilon~+~{| delta |} over 2>,



Where <$Etau> is the interval since the original timestamp (from which <$Etheta> and 

<$Edelta> were determined) was transmitted to the present time and <$Eepsilon sub 

sigma> is the filter dispersion (see clock- filter procedure below). The variables 

relative to the root of the synchronization subnet via peer i are determined as 

follows:



       <$ETHETA sub i~==~theta sub i> ,

       <$EDELTA sub i~==~roman peer.rootdelay~+~delta sub i> ,

       <$EEPSILON sub i~==~roman peer.rootdispersion~+~epsilon sub i~+~phi tausub i>,

       <$ELAMBDA sub i~==~EPSILON sub i~+~{| DELTA sub i |} over 2>,



where all variables are understood to pertain to the ith peer. Finally, assuming the 

ith peer is selected for synchronization, the system variables are determined as 

follows:



       <$ETHETA~=~>combined final offset ,

       <$EDELTA~=~DELTA sub i> ,

       <$EEPSILON~=~EPSILON sub i~+~epsilon sub xi~+~| THETA |> ,

       <$ELAMBDA~=~LAMBDA sub i>

Example 2: Transmit Procedure



The following initializes the packet buffer and copies the packet variables. The value 

skew is necessary to account for the skew-error accumulated over the interval since 

the local clock was last set.



       <$Eroman pkt.peeraddr~<<-~roman peer.hostaddr>;         /* copy system and 

peer variables */

       <$Eroman pkt.peerport~<<-~roman peer.hostport>;

       <$Eroman pkt.hostaddr~<<-~roman peer.peeraddr>;

       <$Eroman pkt.hostport~<<-~roman peer.peerport>;

       <$Eroman pkt.leap~<<-~roman sys.leap>;

       <$Eroman pkt.version~<<-~roman NTP.VERSION>;

       <$Eroman pkt.mode~<<-~roman peer.mode>;

       <$Eroman pkt.stratum~<<-~roman sys.stratum>;

       <$Eroman pkt.poll~<<-~roman peer.hostpoll>;

       <$Eroman pkt.precision~<<-~roman sys.precision>;

       <$Eroman pkt.rootdelay~<<-~roman sys.rootdelay>;

       if (sys.leap = 112 or (sys.clock <196> sys.reftime) >> NTP.MAXAGE)

               <$Eskew~<<-~roman NTP.MAXSKEW>;

       else

               <$Eskew~<<-~phi roman {(sys.clock~-~sys.reftime)}>;

       <$Eroman {pkt.rootdispersion~<<-~roman sys.rootdispersion~+~(1~<< 

<<~sys.precision)}~+~skew>;

       <$Eroman pkt.refid~<<-~roman sys.refid>;

       <$Eroman pkt.reftime~<<-~roman sys.reftime>

Example 3: Receive Procedure



If there is no match a new instantiation of the protocol machine is created and the 

association mobilized.



       if (<$Eroman pkt.version~!=~roman NTP.VERSION>) exit;

      #ifdef (control messages implemented)

               if (<$Eroman pkt.mode~=~6>) call control-message;

               #endef

       for (all associations)                  /* access control goes here */

               match addresses and ports to associations;

       if (no matching association)

               call receive-instantiation procedure;   /* create association */

Example 4: Packet Procedure



In case of broadcast mode (5) the apparent roundtrip delay will be zero and the full 

accuracy of the time-transfer operation may not be achievable. However, the accuracy 

achieved may be adequate for most purposes. The poll-update procedure is called with 

argument peer.hostpoll (peer.peerpoll may have changed).



begin packet procedure



       <$Eroman peer.rec~<<-~roman sys.clock>;     /*capture receive timestamp */

       if (<$Eroman pkt.mode ~!=~5>) begin

               <$Etest1~<<-~( roman {pkt.xmt~!=~peer.org})>;   /* test1 */

               <$Etest2~<<-~( roman {pkt.org~=~peer.xmt})>;    /* test2 */

               endif

       else begin

               <$Eroman pkt.org~<<-~roman peer.rec>;   /* fudge missing timestamps */

               <$Eroman pkt.rec~<<-~roman pkt.xmt>;

               <$Etest1~<<-~bold roman true>;              /* fake tests */

               <$Etest2~<<-~bold roman true>;

               endif

       <$Eroman peer.org~<<-~roman pkt.xmt>;          /* update originate timestamp */

       <$Eroman peer.peerpoll~<<-~roman pkt.poll>;    /* adjust poll interval */

       call poll-update(peer.hostpoll)

Example 5: Primary-Clock Procedure



The distance procedure calculates the root delay <$EDELTA>, root dispersion <$EEPSILON> 

and root synchronization distance <$ELAMBDA> via the peer to the root of the 

synchronization subnet. The host will not synchronize to the selected peer if the 

distance is greater than NTP.MAXDISTANCE. The reason for the minimum clamp at 

NTP.MINDISPERSE is to discourage subnet route flaps that can happen with Bellman-Ford 

algorithms and small roundtrip delays.



       <$ELAMBDA~

 <~>an distance (peer)>;                         /* update system variables */

       if (<$ELAMBDA~>>=~roman NTP.MAXDISTANCE>) exit;

       <$Eroman sys.leap~<<-~roman peer.leap>;

       <$Eroman sys.stratum~<<-~roman peer.stratum~+~1>;

       <$Eroman sys.refid~<<-~roman peer.peeraddr>;

       call local-clock;

       if (local clock reset) begin           /* if reset, clear state variables */

               <$Eroman sys.leap~<<-~11 sub 2>;

               for (all peers) call clear;

               endif

       else begin

               <$Eroman sys.peer~<<-~peer>;   /* if not, adjust local clock */

               <$Eroman sys.rootdelay~<<-~DELTA>;

               <$Eroman sys.rootdispersion~<<-~EPSILON~+~max 

(epsilon sub xi~+~| THETA |,~roman NTP.MINDISPERSE)>;

               endif

       <$Eroman sys.reftime~<<-~roman sys.clock>;

       end clock-update procedure;

Example 6: Initialization Procedure



The initialization procedure is called upon reboot or restart of the NTP daemon. The 

local clock is presumably undefined at reboot; however, in some equipment an estimate 

is available from the reboot environment, such as a battery-backed clock/calendar. 

The precision variable is determined by the intrinsic architecture of the local 

hardware clock. The authentication variables are used only if the authentication 

mechanism described in Appendix C is implemented. The values of these variables 

are determined using procedures beyond the scope of NTP itself.



begin initialization procedure



       #ifdef (authentication implemented)     / * see Appendix C */

               <$Eroman sys.keys~<<-~as~required>;

               #endef;

       <$Eroman sys.leap~<<-~11 sub 2>;           /* copy variables */

       <$Eroman sys.stratum~<<-~0~(undefined)>;

       <$Eroman sys.precision~<<-~host~precision>;

       <$Eroman sys.rootdelay~<<-~0~(undefined)>;

       <$Eroman sys.rootdispersion~<<-~0~(undefined)>;

       <$Eroman sys.refid~<<-~0~(undefined)>;

       <$Eroman sys.reftime~<<-~0~(undefined)>;

       <$Eroman sys.clock~<<-~external~reference>;

       <$Eroman sys.peer~<<-~roman NULL>;

       <$Eroman sys.poll~<<-~roman NTP.MINPOLL>;

       for (all configured peers)         /* create configured associations */

               call initialization-instantiation procedure;

       end initialization procedure;

Example 7: Initialization-Instantiation Procedure



This implementation-specific procedure is called from the initialization procedure to 

define an association. The addresses and modes of the peers are determined using 

information read during the reboot procedure or as the result of operator commands. 

The authentication variables are used only if the authentication mechanism 

described in Appendix C is implemented. The values of these variables are determined 

using procedures beyond the scope of NTP itself. With the authentication bits set as 

suggested, only properly authenticated peers can become the synchronization source.



begin initialization-instantiation procedure



       <$Eroman peer.config~<<-~1>;

       #ifdef (authentication implemented)     /* see Appendix C */

               <$Eroman peer.authenable~<<-~1~(suggested)>;

               <$Eroman peer.authentic~<<-~0>;

               <$Eroman peer.hostkeyid~<<-~as~required>;

               <$Eroman peer.peerkeyid~<<-~0>;

               #endef;

       <$Eroman peer.peeraddr~<<-~peer~IP~address>;    /* copy variables */

       <$Eroman peer.peerport~<<-~roman NTP.PORT>;

       <$Eroman peer.hostaddr~<<-~host~IP~address>;

       <$Eroman peer.hostport~<<-~roman NTP.PORT>;

       <$Eroman peer.mode~<<-~host~mode>;

       <$Eroman peer.peerpoll~<<-~0~(undefined)>;

       <$Eroman peer.timer~<<-~0>;

       <$Eroman peer.delay~<<-~0~(undefined)>;

       <$Eroman peer.offset~<<-~0~(undefined)>;

       call clear;           /* initialize association */

       end initialization-instantiation procedure;

Example 8: Receive-Instantiation Procedure



The receive-instantiation procedure is called from the receive procedure when a new 

peer is discovered. It initializes the peer variables and mobilizes the association. 

The authentication variables are used only if the authentication mechanism 

described in Appendix C is implemented. If implemented, only properly authenticated 

non-configured peers can become the synchronization source.



begin receive-instantiation procedure



       #ifdef (authentication implemented)     /* see Appendix C */

               <$Eroman peer.authenable~<<-~0>;

               <$Eroman peer.authentic~<<-~0>;

               <$Eroman peer.hostkeyid~<<-~as~required>;

               <$Eroman peer.peerkeyid~<<-~0>;

               #endef

       <$Eroman peer.config~<<-~0>;          /* copy variables */

       <$Eroman peer.peeraddr~<<-~roman pkt.peeraddr>;

       <$Eroman peer.peerport~<<-~roman pkt.peerport>;

       <$Eroman peer.hostaddr~<<-~roman pkt.hostaddr>;

       <$Eroman peer.hostport~<<-~roman pkt.hostport>;

       if (pkt.mode = 3)       /* determine mode */

               <$Eroman peer.mode~<<-~4>;

               else

               <$Eroman peer.mode~<<-~2>;

       <$Eroman peer.peerpoll~<<-~0~(undefined)>;

       <$Eroman peer.timer~<<-~0>;

       <$Eroman peer.delay~<<-~0~(undefined)>;

       <$Eroman peer.offset~<<-~0~(undefined)>;

       call clear;          /* initialize association */

       end receive-instantiation procedure;

Example 9: Primary Clock-Instantiation Procedure



This procedure is called from the initialization procedure in order to set up the 

state variables for the primary clock. The value for peer.precision is determined 

from the radio clock specification and hardware interface. The value for 

peer.rootdispersion is nominally ten times the inherent maximum error of the 

radio clock; for instance, <$E10~mu s> for a calibrated atomic clock, 10 ms for 

a WWVB or GOES radio clock and 100 ms for a less accurate WWV radio clock.



begin clock-instantiation procedure



       <$Eroman peer.config~<<-~1>;         /* copy variables */

       <$Eroman peer.peeraddr~<<-~0~undefined>;

       <$Eroman peer.peerport~<<-~0~(not~used)>;

       <$Eroman peer.hostaddr~<<-~0~(not~used)>;

       <$Eroman peer.hostport~<<-~0~(not~used)>;

       <$Eroman peer.leap~<<-~11 sub 2>;

       <$Eroman peer.mode~<<-~0~(not~used)>;

       <$Eroman peer.stratum~<<-~0>;

       <$Eroman peer.peerpoll~<<-~0~(undefined)>;

       <$Eroman peer.precision~<<-~clock~precision>;

       <$Eroman peer.rootdelay~<<-~0>;

       <$Eroman peer.rootdispersion~<<-~clock~dispersion>;

       <$Eroman peer.refid~<<-~0~(not~used)>;

       <$Eroman peer.reftime~<<-~0~(undefined)>;

       <$Eroman peer.timer~<<-~0>;

       <$Eroman peer.delay~<<-~0~(undefined)>;

       <$Eroman peer.offset~<<-~0~(undefined)>;

       call clear;       /* initialize association */

       end clock-instantiation procedure;

■ Parent layer
■ Child layer

UDP

NTP