RFC INDEX PAGE
Google
 

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.

The HTML presentation of this document is copyrighted by Grafman Productions.
Copyright © 1997 - Grafman Productions - ALL RIGHTS RESERVED
Grafman Productions