path: root/share/doc/smm/12.timed/timed.ms

.\" $FreeBSD$
.\"
.\" Copyright (c) 1986, 1993
.\"	The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"	This product includes software developed by the University of
.\"	California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"	@(#)timed.ms	8.1 (Berkeley) 6/8/93
.\"
.TL
The Berkeley
.UX
.br
Time Synchronization Protocol
.AU
Riccardo Gusella, Stefano Zatti, and James M. Bloom
.AI
Computer Systems Research Group
Computer Science Division
Department of Electrical Engineering and Computer Science
University of California, Berkeley
Berkeley, CA 94720
.FS
This work was sponsored by the Defense Advanced Research Projects Agency
(DoD), monitored by the Naval Electronics Systems
Command under contract No. N00039-84-C-0089, and by the Italian CSELT
Corporation.
The views and conclusions contained in this document are those of the
authors and should not be interpreted as representing official policies,
either expressed or implied, of the Defense Research Projects Agency,
of the US Government, or of CSELT.
.FE
.LP
.OH 'The Berkeley UNIX Time Synchronization Protocol''SMM:12-%'
.EH 'SMM:12-%''The Berkeley UNIX Time Synchronization Protocol'
.SH
Introduction
.PP
The Time Synchronization Protocol (TSP)
has been designed for specific use by the program \fItimed\fP,
a local area network clock synchronizer for
the UNIX 4.3BSD operating
system.
Timed is built on the DARPA UDP protocol [4] and
is based on a master slave scheme.
.PP
TSP serves a dual purpose.
First, it supports messages for the synchronization of the clocks
of the various hosts in a local area network.
Second, it supports messages for the election that occurs
among slave time daemons when, for any reason, the master disappears.
The synchronization mechanism and the election procedure
employed by the program timed are described
in other documents [1,2,3].
.PP
Briefly, the synchronization software, which works in a
local area network, consists of a collection of \fItime daemons\fP
(one per machine) and is based on a master-slave
structure.
The present implementation keeps processor clocks synchronized
within 20 milliseconds.
A \fImaster time daemon\fP measures the time
difference between the clock of the machine on which it
is running and those of all other machines.  The current implementation
uses ICMP \fITime Stamp Requests\fP [5] to measure the clock difference
between machines.
The master computes the \fInetwork time\fP as the average of the
times provided by nonfaulty clocks.\**
.FS
A clock is considered to be faulty when its value
is more than a small specified
interval apart from the majority of the clocks
of the machines on the same network.
See [1,2] for more details.
.FE
It then sends to each \fIslave time daemon\fP the
correction that should be performed on the clock of its machine.
This process is repeated periodically.
Since the correction is expressed as a time difference rather than an
absolute time, transmission delays do not interfere with synchronization.
When a machine comes up and joins the network,
it starts a slave time daemon, which
will ask the master for the correct time and will reset the machine's clock
before any user activity can begin.
The time daemons therefore maintain a single network time in spite of
the drift of clocks away from each other.
.PP
Additionally, a time daemon on gateway machines may run as
a \fIsubmaster\fP.
A submaster time daemon functions as a slave on one network that
already has a master and as master on other networks.
In addition, a submaster is responsible for propagating broadcast
packets from one network to the other.
.PP
To ensure that service provided is continuous and reliable,
it is necessary to implement an election algorithm that will elect a
new master should the machine running the current master crash, the master
terminate (for example, because of a run-time error), or the network be
partitioned.
Under our algorithm, slaves are able to realize when the master has
stopped functioning and to elect a new master from among themselves.
It is important to note that since the failure of the master results
only in a gradual divergence of clock values, the election
need not occur immediately.
.PP
All the communication occurring among time daemons uses the TSP
protocol.
While some messages need not be sent in a reliable way,
most communication in TSP requires reliability not provided by the underlying
protocol.
Reliability is achieved by the use of acknowledgements, sequence numbers, and
retransmission when message losses occur.
When a message that requires acknowledgment is not acknowledged after
multiple attempts,
the time daemon that has sent the message will assume that the
addressee is down.
This document will not describe the details of how reliability is
implemented, but will only point out when
a message type requires a reliable transport mechanism.
.PP
The message format in TSP is the same for all message types;
however, in some instances, one or more fields are not used.
The next section describes the message format.
The following sections describe
in detail the different message types, their use and the contents
of each field.  NOTE:  The message format is likely to change in
future versions of timed.
.sp 2
.SH
Message Format
.PP
All fields are based upon 8-bit bytes.  Fields should be sent in
network byte order if they are more than one byte long.
The structure of a TSP message is the following:
.IP 1)
A one byte message type.
.IP 2)
A one byte version number, specifying the protocol version which the
message uses.
.IP 3)
A two byte sequence number to be used for recognizing duplicate messages
that occur when messages are retransmitted.
.IP 4)
Eight bytes of packet specific data.  This field contains two 4 byte time
values, a one byte hop count, or may be unused depending on the type
of the packet.
.IP 5)
A zero-terminated string of up to 256 \s-2ASCII\s+2 characters with the name of
the machine sending the message.
.PP
The following charts describe the message types,
show their fields, and explain their usages.
For the purpose of the following discussion, a time daemon can
be considered to be in
one of three states: slave, master, or candidate for election to master.
Also, the term \fIbroadcast\fP refers to
the sending of a message to all active time daemons.
.sp 1
.SH
Adjtime Message
.so time
.LP
Type: TSP_ADJTIME (1)
.sp 1
.PP
The master sends this message to a slave to communicate
the difference between
the clock of the slave and
the network time the master has just computed.
The slave will accordingly
adjust the time of its machine.
This message requires an acknowledgment.
.sp 1
.SH
Acknowledgment Message
.so unused
.LP
Type: TSP_ACK (2)
.sp 1
.PP
Both the master and the slaves use this message for
acknowledgment only.
It is used in several different contexts, for example
in reply to an Adjtime message.
.sp 1
.SH
Master Request Message
.so unused
.LP
Type: TSP_MASTERREQ (3)
.sp 1
.PP
A newly-started time daemon broadcasts this message to
locate a master.  No other action is implied by this packet.
It requires a Master Acknowledgment.
.sp 1
.SH
Master Acknowledgement
.so unused
.LP
Type: TSP_MASTERACK (4)
.sp 1
.PP
The master sends this message to acknowledge the Master Request message
and the Conflict Resolution Message.
.sp 1
.SH
Set Network Time Message
.so date
.LP
Type: TSP_SETTIME (5)
.sp 1
.PP
The master sends this message to slave time daemons to set their time.
This packet is sent to newly started time daemons and when the network
date is changed.
It contains the master's time as an approximation of the network time.
It requires an acknowledgment.
The next
synchronization round will eliminate the small time difference
caused by the random delay in the communication channel.
.sp 1
.SH
Master Active Message
.so unused
.LP
Type: TSP_MASTERUP (6)
.sp 1
.PP
The master broadcasts this message to
solicit the names of the active slaves.
Slaves will reply with a Slave Active message.
.sp 1
.SH
Slave Active Message
.so unused
.LP
Type: TSP_SLAVEUP (7)
.sp 1
.PP
A slave sends this message to the master in answer to a Master Active message.
This message is also sent when a new slave starts up to inform the master that
it wants to be synchronized.
.sp 1
.SH
Master Candidature Message
.so unused
.LP
Type: TSP_ELECTION (8)
.sp 1
.PP
A slave eligible to become a master broadcasts this message when its election
timer expires.
The message declares that the slave wishes to become the new master.
.sp 1
.SH
Candidature Acceptance Message
.so unused
.LP
Type: TSP_ACCEPT (9)
.sp 1
.PP
A slave sends this message to accept the candidature of the time daemon
that has broadcast an Election message.
The candidate will add the slave's name to the list of machines that it
will control should it become the master.
.sp 1
.SH
Candidature Rejection Message
.so unused
.LP
Type: TSP_REFUSE (10)
.sp 1
.PP
After a slave accepts the candidature of a time daemon, it will reply
to any election messages from other slaves
with this message.
This rejects any candidature other than the first received.
.sp 1
.SH
Multiple Master Notification Message
.so unused
.LP
Type: TSP_CONFLICT (11)
.sp 1
.PP
When two or more masters reply to a Master Request message, the slave
uses this message to inform one of them that more than one master exists.
.sp 1
.SH
Conflict Resolution Message
.so unused
.LP
Type: TSP_RESOLVE (12)
.sp 1
.PP
A master which has been informed of the existence of other masters
broadcasts this message to determine who the other masters are.
.sp 1
.SH
Quit Message
.so unused
.LP
Type: TSP_QUIT (13)
.sp 1
.PP
This message is sent by the master in three different contexts:
1) to a candidate that broadcasts a Master Candidature message,
2) to another master when notified of its existence,
3) to another master if a loop is detected.
In all cases, the recipient time daemon will become a slave.
This message requires an acknowledgement.
.sp 1
.SH
Set Date Message
.so date
.LP
Type: TSP_SETDATE (22)
.sp 1
.PP
The program \fIdate\fP\|(1) sends this message to the local time daemon
when a super-user wants to set the network date.
If the local time daemon is the master, it will set the date;
if it is a slave, it will communicate the desired date to the master.
.sp 1
.SH
Set Date Request Message
.so date
.LP
Type: TSP_SETDATEREQ (23)
.sp 1
.PP
A slave that has received a Set Date message will communicate the
desired date to the master using this message.
.sp 1
.SH
Set Date Acknowledgment Message
.so unused
.LP
Type: TSP_DATEACK (16)
.sp 1
.PP
The master sends this message to a slave in acknowledgment of a
Set Date Request Message.
The same message is sent by the local time daemon to the program
\fIdate(1)\fP to confirm that the network date has been set by the
master.
.sp 1
.SH
Start Tracing Message
.so unused
.LP
Type: TSP_TRACEON (17)
.sp 1
.PP
The controlling program \fItimedc\fP sends this message to the local
time daemon to start the recording in a system file of
all messages received.
.sp 1
.SH
Stop Tracing Message
.so unused
.LP
Type: TSP_TRACEOFF (18)
.sp 1
.PP
\fITimedc\fP sends this message to the local
time daemon to stop the recording of
messages received.
.sp 1
.SH
Master Site Message
.so unused
.LP
Type: TSP_MSITE (19)
.sp 1
.PP
\fITimedc\fP sends this message to the local time daemon to find out
where the master is running.
.sp 1
.SH
Remote Master Site Message
.so unused
.LP
Type: TSP_MSITEREQ (20)
.sp 1
.PP
A local time daemon broadcasts this message to find the location
of the master.
It then uses the Acknowledgement message to
communicate this location to \fItimedc\fP.
.sp 1
.SH
Test Message
.so unused
.LP
Type: TSP_TEST (21)
.sp 1
.PP
For testing purposes, \fItimedc\fP sends this message to a slave
to cause its election timer to expire.  NOTE: \fItimed\fP
is not normally compiled to support this.
.sp 1
.SH
.SH
Loop Detection Message
.so loop
.LP
Type: TSP_LOOP (24)
.sp 1
.PP
This packet is initiated by all masters occasionally to attempt to detect loops.
All submasters forward this packet onto the networks over which they are master.
If a master receives a packet it sent out initially,
it knows that a loop exists and tries to correct the problem.
.SH
References
.IP 1.
R. Gusella and S. Zatti,
\fITEMPO: A Network Time Controller for Distributed Berkeley UNIX System\fP,
USENIX Summer Conference Proceedings, Salt Lake City, June 1984.
.IP 2.
R. Gusella and S. Zatti, \fIClock Synchronization in a Local Area Network\fP,
University of California, Berkeley, Technical Report, \fIto appear\fP.
.IP 3.
R. Gusella and S. Zatti,
\fIAn Election Algorithm for a Distributed Clock Synchronization Program\fP,
University of California, Berkeley, CS Technical Report #275, Dec. 1985.
.IP 4.
Postel, J., \fIUser Datagram Protocol\fP, RFC 768.
Network Information Center, SRI International, Menlo Park, California,
August 1980.
.IP 5.
Postel, J., \fIInternet Control Message Protocol\fP, RFC 792.
Network Information Center, SRI International, Menlo Park, California,
September 1981.