ARPANET 1822L Host Access Protocol
RFC 802

Document Type RFC - Unknown (November 1981; No errata)
Obsoleted by RFC 851
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 802 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
RFC 802: The ARPANET 1822L Host Access Protocol

                         Andrew G. Malis
                     Netmail: malis@bbn-unix

                  Bolt Beranek and Newman Inc.

                          November 1981



RFC 802                                           Andrew G. Malis

                        Table of Contents

1   INTRODUCTION.......................................... 1
2   THE ARPANET 1822L HOST ACCESS PROTOCOL................ 4
2.1   Addresses and Names................................. 6
2.2   Name Authorization and Effectiveness................ 8
2.3   Uncontrolled Messages.............................. 14
2.4   The Short-Blocking Feature......................... 15
2.4.1   Host Blocking.................................... 16
2.4.2   Reasons for Host Blockage........................ 19
2.5   Establishing Host-IMP Communications............... 22
3   1822L LEADER FORMATS................................. 25
3.1   Host-to-IMP 1822L Leader Format.................... 26
3.2   IMP-to-Host 1822L Leader Format.................... 34
4   REFERENCES........................................... 42

                              - i -



RFC 802                                           Andrew G. Malis

                             FIGURES

1822 Address Format....................................... 6
1822L Name Format......................................... 7
1822L Address Format...................................... 7
Communications between different host types.............. 13
Host-to-IMP 1822L Leader Format.......................... 27
NDM Message Format....................................... 30
IMP-to-Host 1822L Leader Format.......................... 35

                             - ii -



RFC 802                                           Andrew G. Malis

1  INTRODUCTION

This document proposes two major changes to the  current  ARPANET

host  access  protocol.  The first change will allow hosts to use

logical addressing (i.e., host addresses that are independent  of

their  physical location on the ARPANET) to communicate with each

other, and the second will allow a host to shorten the amount  of

time  that  it  may  be  blocked  by  its IMP after it presents a

message to the network (currently,  the  IMP  can  block  further

input from a host for up to 15 seconds).

The new host access protocol is known as the ARPANET  1822L  (for

Logical)  Host  Access Protocol, and it represents an addition to

the current ARPANET 1822 Host Access Protocol, which is described

in  sections  3.3  and  3.4 of BBN Report 1822 [1].  Although the

1822L protocol uses different  Host-IMP  leaders  than  the  1822

protocol,  hosts  using  either  protocol can readily communicate

with each other (the IMPs handle the translation automatically).

The new option for shortening the host blocking timeout is called

the short-blocking feature, and it replaces the non-blocking host

interface described in section 3.7 of Report 1822.  This  feature

will  be  available  to  all  hosts  on  C/30  IMPs (see the next

paragraph), regardless of whether they  use  the  1822  or  1822L

protocol.

                              - 1 -



RFC 802                                           Andrew G. Malis

There is one major restriction  to  the  new  capabilities  being

described.   Both  the  1822L  protocol  and  the  short-blocking

feature will be implemented on C/30 IMPs only, and will therefore

only be useable by hosts connected to C/30 IMPs, as the Honeywell

and Pluribus IMPs do not have sufficient memory to hold  the  new

programs  and  tables.   This restriction also means that logical

addressing cannot be used to address a host on  a  non-C/30  IMP.

However, the ARPANET will shortly be completely converted to C/30

IMPs, and at that time this  restriction  will  no  longer  be  a

problem.

I will try to keep my terminology consistent with  that  used  in

Report  1822, and will define new terms when they are first used.

Of course, familiarity with Report 1822 (section 3 in particular)

is assumed.

This document  makes  many  references  to  Report  1822.   As  a

convenient  abbreviation,  I  will  use  "see 1822(x)" instead of

"please refer to Report 1822, section x, for further details".

This document is a proposal, not a description of an  implemented

system.   Thus,  described  features  are subject to change based

upon responses to this  document  and  restrictions  that  become

evident  during  implementation.   However,  any such changes are

expected to be minor.  A new RFC will be made available once  the

                              - 2 -



RFC 802                                           Andrew G. Malis

implementation  is  complete containing the actual as-implemented

description.

Finally, I would like to thank Dr. Eric C. Rosen, who wrote  most
Show full document text