rfc1059.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   Select Weight (PEER.SELECT)

      When the selection algorithm suggested in Section 4 is used, this
      is the select weight used to discard outlyers.  data.  While a
      value of 0.75 is suggested, the value may be changed to suit local
      conditions on particular peer paths.

3.3.  Modes of Operation

   An NTP host can operate in three modes:  client, server and
   symmetric.  The mode of operation is determined by whether the source
   port (peer.srcport) or destination port (peer.dstport) peer variables
   contain the assigned NTP service port number NTP.PORT (123) as shown
   in the following table.









Mills                                                          [Page 21]

RFC 1059                 Network Time Protocol                 July 1988


           peer.srcport    peer.dstport    Mode
           -------------------------------------------
           not NTP.PORT    not NTP.PORT    not possible
           not NTP.PORT    NTP.PORT        server
           NTP.PORT        not NTP.PORT    client
           NTP.PORT        NTP.PORT        symmetric

   A host operating in client mode occasionally sends an NTP message to
   a host operating in server mode.  The server responds by simply
   interchanging addresses and ports, filling in the required
   information and returning the message to the client.  Servers then
   need retain no state information between client requests.  Clients
   are free to manage the intervals between sending NTP messages to suit
   local conditions.

   In symmetric mode the client/server distinction disappears.  Each
   host maintains a table with as many entries as active peers.  Each
   entry includes a code uniquely identifying the peer (e.g.,  Internet
   address and port), together with status information and a copy of the
   timestamps last received.  A host operating in symmetric mode
   periodically sends NTP messages to each peer including the latest
   copy of the timestamps.  The intervals between sending NTP messages
   are managed jointly by the host and each peer using the polling
   variables peer.ppoll and peer.hpoll.

   When a pair of peers operating in symmetric mode exchange NTP
   messages and each determines that the other is reachable, an
   association is formed.  One or both peers must be in active state;
   that is, sending messages to the other regardless of reachability
   status.  A peer not in active state is in passive state.  If a peer
   operating in passive state discovers that the other peer is no longer
   reachable, it ceases sending messages and reclaims the storage and
   timer resources used by the association.  A peer operating in client
   mode is always in active state, while a peer operating in server mode
   is always in passive state.

3.4.  Event Processing

   The significant events of interest in NTP occur upon expiration of
   the peer timer, one of which is dedicated to each peer operating in
   symmetric or client modes, and upon arrival of an NTP message from
   the various peers.  An event can also occur as the result of an
   operator command or detected system fault, such as a primary clock
   failure.  This section describes the procedures invoked when these
   events occur.






Mills                                                          [Page 22]

RFC 1059                 Network Time Protocol                 July 1988


3.4.1.  Timeout Procedure

   The timeout procedure is called in client and symmetric modes when
   the peer timer (peer.timer) reaches the value of the timer threshold
   (peer.threshold) variable.  First, the reachability register
   (peer.reach) is shifted one position to the left and a zero replaces
   the vacated bit.  Then an NTP message is constructed and sent to the
   peer.  If operating in active state or in passive state and
   peer.reach is nonzero (reachable), the peer.timer is reinitialized
   (resumes counting from zero) and the value of peer.threshold is set
   to:

           peer.threshold <- max( min( peer.ppoll, peer.hpoll,
                           NTP.MAXPOLL), NTP.MINPOLL) .

   If operating in active state and peer.reach is zero (unreachable),
   the peer variables are updated as follows:

                   peer.hpoll <- NTP.MINPOLL
                   peer.disp <- NTP.MAXDISP
                   peer.filter <- 0 (cleared)
                   peer.org <- 0
                   peer.rec <- 0

   Then the clock selection algorithm is called, which may result in a
   new clock source (sys.peer).  In other cases the protocol ceases
   operation and the storage and timer resources are reclaimed for
   subsequent use.

   An NTP message is constructed as follows (see Appendices A and B for
   formats).  First, the IP and UDP packet variables are copied from the
   peer variables (note the interchange of source and destination
   addresses and ports):

           pkt.srcadr <- peer.dstadr       pkt.srcport <- peer.dstport
           pkt.dstadr <- peer.srcadr       pkt.dstport <- peer.srcport

   Next, the NTP packet variables are copied (rescaled as necessary)
   from the system and peer variables:

           pkt.leap <- sys.leap            pkt.distance <- sys.distance
           pkt.version <- NTP.VERSION      pkt.drift <- sys.drift
           pkt.stratum <- sys.stratum      pkt.refid <- sys.refid
           pkt.poll <- peer.hpoll          pkt.reftime <- sys.reftime
           pkt.precision <- sys.precision

   Finally, the NTP packet timestamp variables are copied, depending on
   whether the peer is operating in symmetric mode and reachable, in



Mills                                                          [Page 23]

RFC 1059                 Network Time Protocol                 July 1988


   symmetric mode and not reachable (but active) or in client mode:

   Symmetric Reachable     Symmetric Active        Client
   - -------------------     -------------------     -------------------
   pkt.org <- peer.org     pkt.org <- 0            pkt.org <- sys.clock
   pkt.rec <- peer.rec     pkt.rec <- 0            pkt.rec <- sys.clock
   pkt.xmt <- sys.clock    pkt.xmt <- sys.clock    pkt.xmt <- sys.clock

   Note that the order of copying should be designed so that the time to
   perform the copy operations themselves does not degrade the
   measurement accuracy, which implies that the sys.clock values should
   be copied last.  The reason for the choice of zeros to fill the
   pkt.org and pkt.rec packet variables in the symmetric unreachable
   case is to avoid the use of old data after a possibly extensive
   period of unreachability.  The reason for the choice of sys.clock to
   fill these variables in the client case is that, if for some reason
   the NTP message is returned by the recipient unaltered, as when
   testing with an Internet-echo server, this convention still allows at
   least the roundtrip time to be accurately determined without special
   handling.

3.4.2.  Receive Procedure

   The receive procedure is executed upon arrival of an NTP message.  If
   the version number of the message (pkt.version) does not match the
   current version number (NTP.VERSION), the message is discarded;
   however, exceptions may be advised on a case-by-case basis at times
   when the version number is changed.

   If the clock of the sender is unsynchronized (pkt.leap = 11), or the
   receiver is in server mode or the receiver is in symmetric mode and
   the stratum of the sender is greater than the stratum of the receiver
   (pkt.stratum > sys.stratum), the message is simply returned to the
   sender along with the timestamps.  In this case the addresses and
   ports are interchanged in the IP and UDP headers:

        pkt.srcadr <-> pkt.dstadr       pkt.srcport <-> pkt.dstport

   The following packet variables are updated from the system variables:

        pkt.leap <- sys.leap            pkt.distance <- sys.distance
        pkt.version <- NTP.VERSION      pkt.drift <- sys.drift
        pkt.stratum <- sys.stratum      pkt.refid <- sys.refid
        pkt.precision <- sys.precision  pkt.reftime <- sys.reftime

   Note that the pkt.poll packet variable is unchanged.  The timestamps
   are updated in the order shown:




Mills                                                          [Page 24]

RFC 1059                 Network Time Protocol                 July 1988


                        pkt.org <- pkt.xmt
                        pkt.rec <- sys.clock
                        pkt.xmt <- sys.clock

   Finally, the message is forwarded to the sender and the server
   receive procedure terminated at this point.

   If the above is not the case, the source and destination Internet
   addresses and ports in the IP and UDP headers are matched to the
   correct peer.  If there is a match, processing continues at the next
   step below.  If there is no match and symmetric mode is not indicated
   (either pkt.srcport or pkt.dstport not equal to NTP.PORT), the
   message must be a reply to a previously sent message from a client
   which is no longer in operation.  In this case the message is dropped
   and the receive procedure terminated at this point.

   If there is no match and symmetric mode is indicated, (both
   pkt.srcport and pkt.dstport equal to NTP.PORT), an implementation-
   specific instantiation procedure is called to create and initialize a
   new set of peer variables and start the peer timer.  The following
   peer variables are set from the IP and UDP headers:

           peer.srcadr <- pkt.srcadr       peer.srcport <- pkt.srcport
           peer.dstadr <- pkt.dstadr       peer.dstport <- pkt.dstport


   The following peer variables are initialized:

                   peer.state <- symmetric (passive)
                   peer.timer <- 0 (enabled)
                   peer.hpoll <- NTP.MINPOLL
                   peer.disp <- NTP.MAXDISP

   The remaining peer variables are undefined and set to zero.

   Assuming that instantiation is complete and that match occurs, the
   least significant bit of the reachability register (peer.reach) is
   set, indicating the peer is now reachable.  The following peer
   variables are copied (rescaled as necessary) from the NTP packet
   variables and system variables:











Mills                                                          [Page 25]

RFC 1059                 Network Time Protocol                 July 1988


           peer.leap <- pkt.leap           peer.distance <- pkt.distance
           peer.stratum <- pkt.stratum     peer.drift <- pkt.drift
           peer.ppoll <- pkt.poll          peer.refid <- pkt.refid
           peer.precision <- pkt.precision peer.reftime <- pkt.reftime
           peer.org <- pkt.xmt             peer.rec <- sys.clock
           peer.threshold <- max( min( peer.ppoll, peer.hpoll,
                           NTP.MAXPOLL), NTP.MINPOLL)

   If either or both the pkt.org or pkt.rec packet variables are zero,
   the sender did not have reliable values for them, so the receive
   procedure is terminated at this point.  If both of these variables
   are nonzero, the roundtrip delay and clock offset relative to the
   peer are calculated as follows.  Number the times of sending and
   receiving NTP messages as shown in Figure 3.1 and let i be an even
   integer.  Then t(i-3), t(i-2) and t(i-1) and t(i) are the contents of
   the pkt.org, pkt.rec, pkt.xmt and peer.rec variables respectively.

                        |                    |
                   t(1) |------------------->| t(2)
                        |                    |
                   t(4) |<-------------------| t(3)
                        |                    |
                   t(5) |------------------->| t(6)
                        |                    |
                   t(8) |<-------------------| t(7)
                        |                    |
                                 ...
                Figure 3.1. Calculating Delay and Offset

   The roundtrip delay d and clock offset c of the receiving peer
   relative to the sending pe