rfc1305.txt

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

single observation. These 3-tuples enter from the most significant
(leftmost) right and are shifted towards the least significant
(rightmost) end and eventually discarded as new observations arrive.

Valid Data Counter (peer.valid): This is an integer counter indicating
the valid samples remaining in the filter register. It is used to
determine the reachability state and when the poll interval should be
increased or decreased.

Offset (peer.offset): This is a signed, fixed-point number indicating
the offset of the peer clock relative to the local clock, in seconds.

Delay (peer.delay): This is a signed fixed-point number indicating the
roundtrip delay of the peer clock relative to the local clock over the
network path between them, in seconds. Note that this variable can take
on both positive and negative values, depending on clock precision and
skew-error accumulation.

Dispersion (peer.dispersion): This is a signed fixed-point number
indicating the maximum error of the peer clock relative to the local
clock over the network path between them, in seconds. Only positive
values greater than zero are possible.

Authentication Variables

When the authentication mechanism suggested in Appendix C is used, the
following state variables are defined in addition to the variables
described previously. These variables are used only if the optional
authentication mechanism described in Appendix C is implemented.

Authentication Enabled Bit (peer.authenable): This is a bit indicating
that the association is to operate in the authenticated mode.

Authenticated Bit (peer.authentic): This is a bit indicating that the
last message received from the peer has been correctly authenticated.

Key Identifier (peer.hostkeyid, peer.peerkeyid, pkt.keyid): This is an
integer identifying the cryptographic key used to generate the message-
authentication code.

Cryptographic Keys (sys.key): This is a set of 64-bit DES keys. Each key
is constructed as in the Berkeley Unix distributions, which consists of
eight octets, where the seven low-order bits of each octet correspond to
the DES bits 1-7 and the high-order bit corresponds to the DES odd-
parity bit 8.

Crypto-Checksum (pkt.check): This is a crypto-checksum computed by the
encryption procedure.

Parameters

Table 4<$&tab4> shows the parameters assumed for all implementations
operating in the Internet system. It is necessary to agree on the values
for these parameters in order to avoid unnecessary network overheads and
stable peer associations. The following parameters are assumed fixed and
applicable to all associations.

Version Number (NTP.VERSION): This is the current NTP version number
(3).

NTP Port (NTP.PORT): This is the port number (123) assigned by the
Internet Assigned Numbers Authority to NTP.

Maximum Stratum (NTP.MAXSTRATUM): This is the maximum stratum value that
can be encoded as a packet variable, also interpreted as
<169>infinity<170> or unreachable by the subnet routing algorithm.

Maximum Clock Age (NTP.MAXAGE): This is the maximum interval a reference
clock will be considered valid after its last update, in seconds.

Maximum Skew (NTP.MAXSKEW): This is the maximum offset error due to skew
of the local clock over the interval determined by NTP.MAXAGE, in
seconds. The ratio <$Ephi~=~roman {NTP.MAXSKEW over NTP.MAXAGE}> is
interpreted as the maximum possible skew rate due to all causes.

Maximum Distance (NTP.MAXDISTANCE): When the selection algorithm
suggested in Section 4 is used, this is the maximum synchronization
distance for peers acceptable for synchronization.

Minimum Poll Interval (NTP.MINPOLL): This is the minimum poll interval
allowed by any peer of the Internet system, in seconds to a power of
two.

Maximum Poll Interval (NTP.MAXPOLL): This is the maximum poll interval
allowed by any peer of the Internet system, in seconds to a power of
two.

Minimum Select Clocks (NTP.MINCLOCK): When the selection algorithm
suggested in Section 4 is used, this is the minimum number of peers
acceptable for synchronization.

Maximum Select Clocks (NTP.MAXCLOCK): When the selection algorithm
suggested in Section 4 is used, this is the maximum number of peers
considered for selection.

Minimum Dispersion (NTP.MINDISPERSE): When the filter algorithm
suggested in Section 4 is used, this is the minimum dispersion increment
for each stratum level, in seconds.

Maximum Dispersion (NTP.MAXDISPERSE): When the filter algorithm
suggested in Section 4 is used, this is the maximum peer dispersion and
the dispersion assumed for missing data, in seconds.

Reachability Register Size (NTP.WINDOW): This is the size of the
reachability register (peer.reach), in bits.

Filter Size (NTP.SHIFT): When the filter algorithm suggested in Section
4 is used, this is the size of the clock filter (peer.filter) shift
register, in stages.
Filter Weight (NTP.FILTER): When the filter algorithm suggested in
Section 4 is used, this is the weight used to compute the filter
dispersion.

Select Weight (NTP.SELECT): When the selection algorithm suggested in
Section 4 is used, this is the weight used to compute the select
dispersion.

Modes of Operation

Except in broadcast mode, an NTP association is formed when two peers
exchange messages and one or both of them create and maintain an
instantiation of the protocol machine, called an association. The
association can operate in one of five modes as indicated by the host-
mode variable (peer.mode): symmetric active, symmetric passive, client,
server and broadcast, which are defined as follows:

Symmetric Active (1): 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 (2): 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 (3): 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 (4): 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 (5): 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.

A host operating in client mode occasionally sends an NTP message to a
host operating in server mode, perhaps right after rebooting and at
periodic intervals thereafter. The server responds by simply
interchanging addresses and ports, filling in the required information
and returning the message to the client. Servers need retain no state
information between client requests, while clients are free to manage
the intervals between sending NTP messages to suit local conditions. In
these modes the protocol machine described in this document can be
considerably simplified to a simple remote-procedure-call mechanism
without significant loss of accuracy or robustness, especially when
operating over high-speed LANs.

In the symmetric modes the client/server distinction (almost)
disappears. Symmetric passive mode is intended for use by time servers
operating near the root nodes (lowest stratum) of the synchronization
subnet and with a relatively large number of peers on an intermittent
basis. In this mode the identity of the peer need not be known in
advance, since the association with its state variables is created only
when an NTP message arrives. Furthermore, the state storage can be
reused when the peer becomes unreachable or is operating at a higher
stratum level and thus ineligible as a synchronization source.

Symmetric active mode is intended for use by time servers operating near
the end nodes (highest stratum) of the synchronization subnet. Reliable
time service can usually be maintained with two peers at the next lower
stratum level and one peer at the same stratum level, so the rate of
ongoing polls is usually not significant, even when connectivity is lost
and error messages are being returned for every poll.

Normally, one peer operates in an active mode (symmetric active, client
or broadcast modes) as configured by a startup file, while the other
operates in a passive mode (symmetric passive or server modes), often
without prior configuration. However, both peers can be configured to
operate in the symmetric active mode. An error condition results when
both peers operate in the same mode, but not symmetric active mode. In
such cases each peer will ignore messages from the other, so that prior
associations, if any, will be demobilized due to reachability failure.

Broadcast mode is intended for operation on high-speed LANs with
numerous workstations and where the highest accuracies are not required.
In the typical scenario one or more time servers on the LAN send
periodic broadcasts to the workstations, which then determine the time
on the basis of a preconfigured latency in the order of a few
milliseconds. As in the client/server modes the protocol machine can be
considerably simplified in this mode; however, a modified form of the
clock selection algorithm may prove useful in cases where multiple time
servers are used for enhanced reliability.

Event Processing

The significant events of interest in NTP occur upon expiration of a
peer timer (peer.timer), one of which is dedicated to each peer with an
active association, 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 reference source failure. This
section describes the procedures invoked when these events occur.

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>). When necessary to
distinguish between them, lower-case Greek letters are used for
variables relative to a peer, while upper-case Greek letters are used
for variables relative to the primary reference source(s), i.e., via the
peer to the root of the synchronization subnet. Subscripts will be used
to identify the particular peer when this is not clear from context. The
algorithms are based on a quantity called the synchronization distance
(<$Elambda ,~LAMBDA>), which is computed from the roundtrip delay and
dispersion as described below.

As described in Appendix H, the peer dispersion <$Eepsilon> includes
contributions due to measurement error <$Erho~=~1~<< <<~roman
sys.precision>, skew-error accumulation <$Ephi tau>, where
<$Ephi~=~roman {NTP.MAXSKEW over NTP.MAXAGE}> is the maximum skew rate
and <$Etau~=~roman {sys.clock~-~peer.update}> is the interval since the
last update, and filter (sample) dispersion <$Eepsilon sub sigma>
computed by the clock-filter algorithm. The root dispersion <$EEPSILON>
includes contributions due to the selected peer dispersion <$Eepsilon>
and skew-error accumulation <$Ephi tau>, together with the root
dispersion for the peer itself. The system dispersion includes the
select (sample) dispersion <$Eepsilon sub xi> computed by the clock-
select algorithm and the absolute initial clock offset <$E| THETA |>
provided to the local-clock algorithm. Both <$Eepsilon> and <$EEPSILON>
are dynamic quantities, since they depend on the elapsed time <$Etau>
since the last update, as well as the sample dispersions calculated by
the algorithms.

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 tau
sub 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> ,

where <$Eepsilon sub xi> is the select dispersion (see clock-selection
procedure below).

Informal pseudo-code which accomplishes these computations is presented
below. Note that the pseudo-code is represented in no particular
language, although it has many similarities to the C language. Specific
de