RFC 547 UNKNOWN DOCUMENTATION · HOST-IMP INTERFACE

Change to the Very Distant Host specification

Corrected specification for connecting distant hosts to IMPs.

On rfc-editor.org ↗
PUBLISHED
August 1973
AUTHORS
D.C. Walden
STREAM
Legacy
DOCUMENT TYPE
Errata for BBN Report 1822
FIGURE CORRECTED
F-4 (Control Word Format)
DOI
10.17487/RFC0547

RFC text

Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                          D. Walden
Request for Comments: 547                                        BBN-NET
NIC: 17793                                                13 August 1973


             Change to the Very Distant Host Specification

   Attached is a new version of figure F-4 for BBN Report 1822,
   Specification for the Interconnection of a Host and an IMP.  Also
   attached is replacement text for the paragraph beginning at the
   bottom of page F-7 and continuing through page F-8.

   Please put this RFC with your copy of 1822 pending update of 1822.

   DCW/ph


                   SPECIAL PACKET BIT ___
                                         |
                                         |
      ___HELLO/I-HEARD-YOU BIT           |      ___ UNUSED __
     |                                   |     |             |
     |                                   |     |             |
     V                                   V     V             V
    _______________________________________________________________
   |   |   |                       |   |   |///////|   |   |///|   |
   |   |   |                       |   |   |///////|   |   |///|   |
   |___|___|___|___|___|___|___|___|___|___|///|///|___|___|///|___|
     ^   ^     PACKET WORD COUNT     ^               ^   ^       ^
     |   |         ( 6 BITS )        |               |   |       |
     |   |                           |               |   |    CHANNEL
     |   |                           |               |   |    NUMBER
     |   |                           |               |   |
     |  PACKET                  HOST/IMP BIT         |  CHANNEL ZERO
     |  ODD/EVEN BIT                                 |  ACKNOWLEDGE BIT
     |                                               |
    LAST PACKET BIT                                CHANNEL ONE
                                                   ACKNOWLEDGEMENT BIT

                          FIG. F-4   CONTROL WORD FORMAT

   The following algorithm is used to decide whether the circuit between
   an IMP and a very distant Host is dead or alive.  We first define
   what we call a special packet -- this is (logically) a one word
   packet consisting of only the control word and having the SPECIAL
   PACKET bit set to one.  All packets which are not special packets
   (i.e., which are regular data packets or null packets) have the
   SPECIAL PACKET bit set to zero.  In a special packet, none of the
   control word fields or bits have their usual meanings; consequently,
   a special packet cannot be used to acknowledge data packets or send
   data.  In a special packet, only one bit other than the SPECIAL
   PACKET bit has any meaning, the HELLO/I-HEARD-YOU bit.

   Every r seconds both IMP and Host (independently) send a HELLO
   packet, a special packet with the HELLO/I-HEARD-YOU bit set to zero.
   When either IMP or Hosts receives a HELLO packet, it must promptly
   (with highest priority) send the other an I-HEARD-YOU packet, a
   special packet with the HELLO/I-HEAR-YOU bit set to one.  In other
   words, the I-HEARD-YOU packet is an acknowledgement of the periodic
   HELLO packet, and a I-HEARD-YOU packet must only be sent as
   acknowledgement for a HELLO packet.  If either IMP or Host sends more
   than t HELLO packets without receiving an I-HEARD-YOU packet in
   acknowledgement, the IMP or Host declares the line dead.  Once either
   IMP or Host declares the line dead, it must send or accept no packets
   (either special or regular) for 2*t*r* seconds to allow the other
   party also to declare the line dead.  After waiting 2*t*r* seconds,
   an attempt is made to bring the line alive.  This is done by sending
   HELLO packets (but no regular packets) every r seconds while noting
   received I-HEARD-YOU packets until k HELLO packets in a row are
   acknowledged with I-HEARD-YOU packets.  While doing this, received
   HELLO packets must be acknowledged with I-HEARD-YOU packets.  Once
   acknowledgement for k HELLO packets have been received in a row
   (i.e., one acknowledgement every r seconds for k intervals[1]), the
   line is declared alive, and regular packets again may be sent,
   received, and acknowledged along with the periodic (every r seconds)
   HELLO packets.  If a regular data packet is received while a party is
   trying to bring the line up (due perhaps to slight timing differences
   between the parties at the ends of the line), the data packet must
   not be acknowledged.

   The odd/even bits, the used/unused bits, and the channel filling and
   emptying sequences must be initialized at start up[2] and
   reinitialized every time the line is declared dead.  If either the
   IMP or Host decides the line is dead, the same action is taken as the
   IMP or Host normally takes when the other's ready line is down.  The
   line being up causes the same action as is normally taken when the
   ready line is up.  The value of r is currently 1.25 seconds, the
   value of t is currently 4, and the value of k is currently also 4.

   It is likely that the values of r, t, and k will be adjusted in the
   future; very distant Host programmers are advised to make it easy to
   change these parameters.

Endnotes

   [1] In particular, the IMP implementation requires the receipt of an
   acknowledgement within r seconds of the transmission of a HELLO
   packet in order to consider that the HELLO packet was successfully
   acknowledged.

   [2] At start-up, the line must be assumed to be dead and the
   procedure of waiting 2*t*r* seconds before sending HELLO packets,
   etc. must be used to bring the line alive initially.


         [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Jeff McClellan 1/98 ]

AI ELI5

On this page
PROBLEMThe Very Distant Host specification in BBN Report 1822 contained an error in a diagram and accompanying text that described how hosts could connect to IMPs.
MECHANISMRFC 547 provides replacement text and a corrected diagram (Figure F-4, the Control Word Format) along with an algorithm describing how IMPs and distant hosts detect when their connection is alive or dead.
WHY IT MATTERSSites could file this RFC with their copy of Report 1822 until that document was updated, correcting the specification without requiring a full revision of the 1822 document.

§1The Fix

RFC 547 provides replacement text and a corrected figure for the Very Distant Host specification section of BBN Report 1822, which defines how a Host connects to an IMP (Interface Message Processor). The document was authored by D. Walden at BBN and sent to the network community asking them to incorporate these corrections with their copies of Report 1822 until that document underwent its next full revision.

Here is the corrected page that goes into your copy of the rulebook about connecting computers to the network.

§2The Control Word Format

The corrected Figure F-4 shows the Control Word Format for IMP-Host communication. The diagram identifies key fields and bits including the LAST PACKET bit, PACKET ODD/EVEN bit, PACKET WORD COUNT (6 bits), HOST/IMP bit, CHANNEL ZERO ACKNOWLEDGE bit, CHANNEL ONE ACKNOWLEDGEMENT bit, CHANNEL NUMBER, the HELLO/I-HEARD-YOU bit, SPECIAL PACKET bit, and unused bits.

A control word is like a label at the top of a message between a computer and the network hardware, telling what kind of message it is and where it should go.

§3Detecting Live and Dead Connections

The replacement text defines an algorithm for deciding whether the circuit between an IMP and a very distant Host is alive or dead. Both the IMP and Host independently send HELLO packets (special packets with the HELLO/I-HEARD-YOU bit set to zero) every r seconds. When either receives a HELLO packet, they must promptly send an I-HEARD-YOU packet in acknowledgement. If either side sends more than t HELLO packets without receiving an I-HEARD-YOU acknowledgement, the circuit is declared dead. After a waiting period of 2*t*r seconds, the party that declared the line dead attempts to bring it back up by sending HELLO packets every r seconds until k HELLO packets in a row are acknowledged with I-HEARD-YOU packets, at which point the line is declared alive again and regular data packets can be exchanged.

Both sides say "hello" every once in a while. If one side doesn't hear back after trying several times, it assumes the connection is broken and stops sending. After waiting a while, it tries saying hello again until it gets answers again.