RFC778 - DCNET Internet Clock Service

RFC778                DCNET Internet Clock Service              D.L. Mills, COMSAT Laboratories                       18 APRil 1981IntrodUCtion     Following  is  a  description  of  the  Internet  ClockService  (ICS)  provided  by  all DCNET hosts.  The service,intended primarily for  clock  synchronization  and  one-waydelay  measurements  with  coOperating  internet  hosts,  isprovided using the Timestamp and Timestamp Reply messages ofthe  proposed  Internet Control Message Protocol (ICMP).  Inaddition, in order to maintain  compatability  with  presentsystems,  this  service  will be provided for a limited timeusing  the   Echo   and   Echo   Reply   messages   of   theGateway-Gateway Protocol (GGP).     It should be understood that ICMP and GGP datagrams arenormally  considered  tightly bound to the Internet Protocol(IP) itself and not directly accessable to  the  user  on  aTOPS-20  system,  for  example.  These datagrams are treatedsomewhat differently from user  datagrams  in  gateways  andDCNET hosts in that certain internal queueing mechanisms arebypassed.  Thus, they can be a useful tool in providing  themost   accurate   and  stable  time  reference.   The  primemotivation for this note is to promote  the  development  ofthis  service  in  other internet hosts and gateways so thatthe feasibility for its use thoughout the community  can  beassessed.ICS Datagrams and Timestamps     At present, the ICS is provided using  either  ICMP  orGGP  datagrams.   The  only difference between these is thatICMP uses protocol number 1 and GGP uses protocol number  3.In the following these will be referred to interchangably asICS datagrams.  ICS datagrams  include  an  internet  headerfollowed 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 justbefore  the datagram is forwarded to the net.  Each of these
                         fields contain the local time at origination.  Although  thelast   two   are   redundant,  they  allow  roundtrip  delaymeasurements  to  be  made  using   remote   hosts   withouttimestamping  facilities.   The "Type" field can be either 8(GGP Echo) or 13 (ICMP Timestamp).  The "Code" field  shouldbe zero.  The "Sequence" field can contain either zero or anoptional sequence number provided by the user.   The  lengthof  the datagram is thus 36 octets inclusive of the 20-octetinternet header and exclusive of the local-network leader.     The host or gateway receiving an ICS datagram fills  inthe  "Receive  Timestamp"  field  just  as  the  datagram isreceived from the net and the "Transmit Timestamp"  just  asit is forwarded back to the sender.  It also sets the "Type"field to 0 (GGP Echo Reply), if the original value was 8, or14  (ICMP  Timestamp  Reply),  if  it was 13.  The remainingfields are unchanged.     The timestamp values are in milliseconds from  midnightUT and are stored right-justified in the 32-bit fields shownabove.  Ordinarily,  all  time  calculations  are  performedmodulo-24 hours in milliseconds.  This provides a convenientmatch to those operating systems  which  maintain  a  systemclock  in ticks past midnight.  The specified timestamp unitof milliseconds is consistent with the accuracy of  existingradio  clocks  and  the  errors eXPected in the timestampingprocess itself.Delay Measurements     Delay measurements can be made with any DCNET  host  bysimply sending an ICS datagram in the above format to it andprocessing the reply.  Let t1, t2 and t3 represent the threetimestamp  fields  of  the reply in order and t4 the time ofarrival at the original sender.  Then the delays,  exclusiveof  internal  processing  within  the DCNET host, are simply(t2 - t1) to the DCNET host, (t4 - t3) for  the  return  andDCNET Internet Clock Service                        PAGE   3(t2 - t1) + (t4 - t3)  for the roundtrip.  Note that, in thecase of the roundtrip, the clock offsets between the sendinghost and DCNET host cancel.     Although ICS datagrams are returned by all DCNET  hostsregardless  of  other connections that may be in use by thathost at any given time, the most useful host  will  probablybe   the   COMSAT-WWV   virtual  host  at  internet  address[29,0,9,2], which is also the  internet  echo  virtual  hostformerly  called  COMSAT-ECH.  This virtual host is residentin  the  COMSAT-GAT  physical  host  at   internet   address[29,0,1,2], which is connected to the ARPANET via the COMSATGateway, Clarksburg SIMP and a 4800-bps line to  IMP  71  atBBN.    The  roundtrip  delay  via  this  path  between  theCOMSAT-GAT  host  and  the  BBN  Gateway  is  typically  550milliseconds 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 theSpectracom radio clock is down or misbehaving) a  "host  notreachable"   GGP   datagram   is   returned.    In   unusualcircumstances a "net not reachable" or "source  quench"  GGPdatagram  could  be  returned.   Note that the references to"GGP" here will be read "ICMP" at  some  appropriate  futuretime.Local Offset Corrections     All DCNET timestamps are  referenced  to  a  designatedvirtual  host  called  COMSAT-WWV (what else?) with internetaddress [29,0,9,2].  This host is equipped with a Spectracomradio  clock  which  normally provides WWVB time and date towithin a millisecond.  The clock  synchronization  mechanismprovides  offset  and  drift  corrections  for  other  hostsrelative to this host; however, offsets up to an appreciablefraction  of  a second routinely occur due to the difficultyof tracking with power-line  clocks  in  some  machines.   Atable  of  the  current  offsets  can  be oBTained using thefollowing 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 "NBSDCNET 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", RFC777,   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   5Following is a specification of  the  ICS  header  in  PDP11code:;; GGP/ICMP Header; .       =       0GH.TYP:  .BLKB   1               ;Message typeGC.RPY   =       0               ;Echo replyGC.UPD   =       1               ;Routing updateGC.ACK   =       2               ;Positive acknowledgment
                         GC.DNR   =       3               ;Destination unreachableGC.SQN   =       4               ;Source quenchGC.RDR   =       5               ;RedirectGC.ECH   =       10              ;EchoGC.STA   =       11              ;Net interface statusGC.NAK   =       12              ;Negative acknowledgmentGC.TIM   =       15              ;TimestampGC.TRP   =       16              ;Timestamp ReplyGH.COD:  .BLKB   1               ;Message codeGH.SEQ:  .BLKW   1               ;Sequence numberGH.HDR   =       .               ;Beginning of original                                 ;internet headerGH.ORG:  .BLKW   2               ;Originating timestampGH.REC:  .BLKW   2               ;Received timestampGH.XMT:  .BLKW   2               ;Transmitted timestampGH.LEN   =       .               ;End of timestamp header     Note that all  PDP11  Word  fields  (.BLKW  above)  are"byte-swapped,"  that  is, the order of byte transmission isthe high-order byte followed by the low-order  byte  of  thePDP11 word.