doc: Add RFC documents

1 files changed, 225 insertions, 0 deletions

diff --git a/doc/rfc/rfc778.txt b/doc/rfc/rfc778.txt
new file mode 100644
index 0000000..265ec28
--- /dev/null
+++ b/doc/rfc/rfc778.txt
@@ -0,0 +1,225 @@
+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.