diff options
Diffstat (limited to 'doc/rfc/rfc778.txt')
| -rw-r--r-- | doc/rfc/rfc778.txt | 225 |
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. |