RFC 778

                DCNET Internet Clock Service
              D.L. Mills, COMSAT Laboratories
                       18 April 1981

Introduction

     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
assessed.

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:

DCNET Internet Clock Service                        PAGE   2

 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

DCNET Internet Clock Service                        PAGE   3

(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
time.

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

DCNET Internet Clock Service                        PAGE   4

    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!).

REFERENCES

[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.

DCNET Internet Clock Service                        PAGE   5

Following is a specification of  the  ICS  header  in  PDP11
code:

;
; 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.