RFC 778

DCNET Internet Clock Service

D.L. Mills, COMSAT Laboratories

18 April 1981


Following is a description of the Internet Clock

Service (ICS) provided by all DCNET hosts. The service,
intended primarily for clock synchronization and one-way
delay measurements with cooperating internet hosts, is
provided using the Timestamp and Timestamp Reply messages of
the proposed Internet Control Message Protocol (ICMP). In
addition, in order to maintain compatability with present
systems, this service will be provided for a limited time
using the Echo and Echo Reply messages of the
Gateway-Gateway Protocol (GGP).
It should be understood that ICMP and GGP datagrams are
normally considered tightly bound to the Internet Protocol
(IP) itself and not directly accessable to the user on a
TOPS-20 system, for example. These datagrams are treated
somewhat differently from user datagrams in gateways and
DCNET hosts in that certain internal queueing mechanisms are
bypassed. Thus, they can be a useful tool in providing the
most accurate and stable time reference. The prime
motivation for this note is to promote the development of
this service in other internet hosts and gateways so that
the feasibility for its use thoughout the community can be

ICS Datagrams and Timestamps

At present, the ICS is provided using either ICMP or

GGP datagrams. The only difference between these is that
ICMP uses protocol number 1 and GGP uses protocol number 3.
In the following these will be referred to interchangably as
ICS datagrams. ICS datagrams include an internet header
followed by an ICS header in the following format:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Type | Code | Sequence |
| Originate Timestamp |
| Receive Timestamp |
| Transmit Timestamp |

ICS Datagram Format

The originator fills in all three timestamp fields just

before the datagram is forwarded to the net. Each of these
fields contain the local time at origination. Although the
last two are redundant, they allow roundtrip delay
measurements to be made using remote hosts without
timestamping facilities. The "Type" field can be either 8
(GGP Echo) or 13 (ICMP Timestamp). The "Code" field should
be zero. The "Sequence" field can contain either zero or an
optional sequence number provided by the user. The length
of the datagram is thus 36 octets inclusive of the 20-octet
internet header and exclusive of the local-network leader.

The host or gateway receiving an ICS datagram fills in

the "Receive Timestamp" field just as the datagram is
received from the net and the "Transmit Timestamp" just as
it is forwarded back to the sender. It also sets the "Type"
field to 0 (GGP Echo Reply), if the original value was 8, or
14 (ICMP Timestamp Reply), if it was 13. The remaining
fields are unchanged.

The timestamp values are in milliseconds from midnight

UT and are stored right-justified in the 32-bit fields shown
above. Ordinarily, all time calculations are performed
modulo-24 hours in milliseconds. This provides a convenient
match to those operating systems which maintain a system
clock in ticks past midnight. The specified timestamp unit
of milliseconds is consistent with the accuracy of existing
radio clocks and the errors expected in the timestamping
process itself.

Delay Measurements

Delay measurements can be made with any DCNET host by

simply sending an ICS datagram in the above format to it and
processing the reply. Let t1, t2 and t3 represent the three
timestamp fields of the reply in order and t4 the time of
arrival at the original sender. Then the delays, exclusive
of internal processing within the DCNET host, are simply
(t2 - t1) to the DCNET host, (t4 - t3) for the return and

(t2 - t1) + (t4 - t3) for the roundtrip. Note that, in the
case of the roundtrip, the clock offsets between the sending
host and DCNET host cancel.

Although ICS datagrams are returned by all DCNET hosts

regardless of other connections that may be in use by that
host at any given time, the most useful host will probably
be the COMSAT-WWV virtual host at internet address
[29,0,9,2], which is also the internet echo virtual host
formerly called COMSAT-ECH. This virtual host is resident
in the COMSAT-GAT physical host at internet address
[29,0,1,2], which is connected to the ARPANET via the COMSAT
Gateway, Clarksburg SIMP and a 4800-bps line to IMP 71 at
BBN. The roundtrip delay via this path between the
COMSAT-GAT host and the BBN Gateway is typically 550
milliseconds as the ICS datagram flies.

As in the case of all DCNET hosts, if the COMSAT-WWV

virtual host is down (in this case possible only if the
Spectracom radio clock is down or misbehaving) a "host not
reachable" GGP datagram is returned. In unusual
circumstances a "net not reachable" or "source quench" GGP
datagram could be returned. Note that the references to
"GGP" here will be read "ICMP" at some appropriate future

Local Offset Corrections

All DCNET timestamps are referenced to a designated

virtual host called COMSAT-WWV (what else?) with internet
address [29,0,9,2]. This host is equipped with a Spectracom
radio clock which normally provides WWVB time and date to
within a millisecond. The clock synchronization mechanism
provides offset and drift corrections for other hosts
relative to this host; however, offsets up to an appreciable
fraction of a second routinely occur due to the difficulty
of tracking with power-line clocks in some machines. A
table of the current offsets can be obtained using the
following procedure.

1. Connect to COMSAT-GAT host at internet address
[29,0,1,2] using TELNET and local echo.

2. Send the command SET HOST HOST. A table with one line
per DCNET host should be returned. Note the entry under the "Offset" column for the WWV host. This contains the offset in milliseconds that should be added to all
    timestamps  generated  by  either  the   COMSAT-GAT   or
    COMSAT-WWV  hosts to yield the correct time as broadcast
    by WWVB.

3. Send the command SET WWV SHOW. A summary of datagram
traffic is returned along with an entry labelled "NBS

time." The string following this is the last reply received from the Spectracom unit in the format:

                  <code>  DDD HH:MM:SS  TZ=00

where <code> is normally <SP> in case the WWVB signal is being received correctly or ? in case it is not. The DDD represents the day of the year and HH:MM:SS the time

    past   UT   midnight.   The  two  digits  following  TZ=
    represent the time zone, here 00 for UT.

4. Close the connection (please!).


[1] ICMP

Postel, J., "Internet Control Message Protocol", RFC 777, USC/Information Sciences Institute, April 1981.

[2] GGP

Strazisar, V., "How to Build a Gateway", IEN 109, Bolt
Beranek and Newman, August 1979.

Following is a specification of the ICS header in PDP11

; GGP/ICMP Header
 .       =       0
GH.TYP:  .BLKB   1               ;Message type
GC.RPY   =       0               ;Echo reply
GC.UPD   =       1               ;Routing update
GC.ACK   =       2               ;Positive acknowledgment
GC.DNR   =       3               ;Destination unreachable
GC.SQN   =       4               ;Source quench
GC.RDR   =       5               ;Redirect
GC.ECH   =       10              ;Echo
GC.STA   =       11              ;Net interface status
GC.NAK   =       12              ;Negative acknowledgment
GC.TIM   =       15              ;Timestamp
GC.TRP   =       16              ;Timestamp Reply
GH.COD:  .BLKB   1               ;Message code
GH.SEQ:  .BLKW   1               ;Sequence number
GH.HDR   =       .               ;Beginning of original
                                 ;internet header
GH.ORG:  .BLKW   2               ;Originating timestamp
GH.REC:  .BLKW   2               ;Received timestamp
GH.XMT:  .BLKW   2               ;Transmitted timestamp
GH.LEN   =       .               ;End of timestamp header

Note that all PDP11 word fields (.BLKW above) are

"byte-swapped," that is, the order of byte transmission is
the high-order byte followed by the low-order byte of the
PDP11 word.