rfc802.txt

RFC 相关的技术文档

    message is submitted and  the  time  the  host  receives  the

    reply,  the  message  is  said to be outstanding. The ARPANET

    allows  only  eight  outstanding  messages   on   any   given

    connection.   If  there  are  eight outstanding messages on a

    given connection, and a ninth is  submitted,  it  cannot  the

    accepted.  If  a message is refused because its connection is

    blocked due to flow control, messages  on  other  connections

    can still be accepted.


    End-to-end flow control is the  most  common  cause  of  host

    blocking in the ARPANET at present.


8.  Destination IMP buffer space shortage: If the host submits  a

    message  of  more  than  1008  bits  (exclusive of the 96-bit

    leader), buffer space at the destination IMP must be reserved

    before  the  message  can  be  accepted.  Buffer space at the

    destination IMP is always reserved on a per-connection basis.

    If  the  destination  IMP  is  heavily loaded, there may be a

    lengthy wait for the buffer space;  this  is  another  common

    cause  of  blocking  in  the  present  ARPANET.  Messages are

    rejected  for  this  reason  based  on   their   length   and

    connection;  messages  of  1008 or fewer bits or messages for

    other connections may still be acceptable.






                             - 21 -




RFC 802                                           Andrew G. Malis



9.  Congestion control: A message may be refused for  reasons  of

    congestion  control if the path via the intermediate IMPs and

    lines to the destination IMP is too heavily loaded to  handle

    additional  traffic.   Messages  to other destinations may be

    acceptable, however.


10.  Local resource shortage: Sometimes the source IMP itself  is

    short  of buffer space, table entries, or some other resource

    that it needs to accept a message.  Unlike the other  reasons

    for message rejection, this resource shortage will affect all

    messages equally,  except  for  uncontrolled  messages.   The

    message's size or connection is not relevant.


The short-blocking feature is available  to  all  hosts  on  C/30

IMPs,  whether they are using the 1822 or 1822L protocol, through

the use of Type 0, sub-type 1 and 2 messages.  A host using these

sub-types  should  be  prepared  to  correctly  handle Incomplete

Transmission messages from the IMP.




2.5  Establishing Host-IMP Communications


When a host comes up on an IMP, or after there has been  a  break

in   the  communications  between  the  host  and  its  IMP  (see

1822(3.2)), the orderly flow of messages between the host and the




                             - 22 -




RFC 802                                           Andrew G. Malis



IMP  needs  to  be properly (re)established.  This allows the IMP

and host to recover from most any failure  in  the  other  or  in

their communications path, including a break in mid-message.


The first messages that a host should send to its IMP  are  three

NOP  messages.   Three  messages  are  required to insure that at

least one message will be properly read by the IMP (the first NOP

could be concatenated to a previous message if communications had

been broken in mid-stream, and the third provides redundancy  for

the   second).    These   NOPs   serve  several  functions:  they

synchronize the IMP with the host, they tell  the  IMP  how  much

padding  the  host  requires  between  the message leader and its

body, and they also tell the IMP whether the host will  be  using

1822 or 1822L leaders.


Similarly, the IMP will send three  NOPs  to  the  host  when  it

detects  that  the host has come up.  Actually, the IMP will send

six NOPs, alternating three 1822  NOPs  with  three  1822L  NOPs.

Thus, the host will see three NOPs no matter which protocol it is

using.   The  NOPs  will  be  followed  by  two  Interface  Reset

messages,  one of each style.  If the IMP receives a NOP from the

host while the above sequence is occurring,  the  IMP  will  only

send  the  remainder  of  the NOPs and the Interface Reset in the

proper style.  The 1822 NOPs will contain the 1822 address of the




                             - 23 -




RFC 802                                           Andrew G. Malis



host interface, and the 1822L NOPs will contain the corresponding

1822L address.


Once the IMP  and  the  host  have  sent  each  other  the  above

messages, regular communications can commence.  See 1822(3.2) for

further details concerning the ready line,  host  tardiness,  and

other issues.





































                             - 24 -




RFC 802                                           Andrew G. Malis



3  1822L LEADER FORMATS


The following sections describe the formats of the  leaders  that

precede  messages  between  an 1822L host and its IMP.  They were

designed to be as compatible with the 1822 leaders  as  possible.

The  second,  fifth,  and  sixth  words  are identical in the two

leaders, and all  of  the  existing  functionality  of  the  1822

leaders has been retained.  The first difference one will note is

in the first word.  The 1822 New Format Flag is now also used  to

identify  the  two  types of 1822L leaders, and the Handling Type

has been moved to the second byte.  The third  and  fourth  words

contain the Source and Destination 1822L Name, respectively.



























                             - 25 -




RFC 802                                           Andrew G. Malis



3.1  Host-to-IMP 1822L Leader Format





               1      4 5      8 9             16
              +--------+--------+----------------+
              |        |  1822L |                |
              | Unused |  H2I   | Handling Type  |
              |        |  Flag  |                |
              +--------+--------+----------------+
               17    20 21 22 24 25            32
              +--------+-+------+----------------+
              |        |T|Leader|                |
              | Unused |R|Flags |  Message Type  |
              |        |C|      |                |
              +--------+-+------+----------------+
               33                              48
              +----------------------------------+
              |                                  |
              |           Source Host            |
              |                                  |
              +----------------------------------+
               49                              64
              +----------------------------------+
              |                                  |
              |         Destination Host         |
              |                                  |
              +----------------------------------+
               65                     76 77    80
              +-------------------------+--------+
              |                         |        |
              |       Message ID        |Sub-type|
              |                         |        |
              +-------------------------+--------+
               81                              96
              +----------------------------------+
              |                                  |
              |              Unused              |
              |                                  |
              +----------------------------------+

           Figure 5. Host-to-IMP 1822L Leader Format





                             - 26 -




RFC 802                                           Andrew G. Malis



Bits 1-4: Unused, must be set to zero.


Bits 5-8: 1822L Host-to-IMP Flag:

     This field is set to decimal 13 (1101 in binary).


Bits 9-16: Handling Type:

     This  field  is  bit-coded  to  indicate  the   transmission

     characteristics  of  the connection desired by the host. See

     1822(3.3).

     Bit 9: Priority Bit:

          Messages with this bit on will be treated  as  priority

          messages.

     Bits 10-16: Unused, must be zero.


Bits 17-20: Unused, must be zero.


Bit 21: Trace Bit:

     If equal to one, this message is designated for  tracing  as

     it proceeds through the network.  See 1822(5.5).


Bits 22-24: Leader Flags:

     Bit 22: A flag available for use by  the  destination  host.

          See 1822(3.3) for a description of its use by the IMP's

          TTY fake host.

     Bits 23-24: Reserved for future use, must be zero.





                             - 27 -




RFC 802                                           Andrew G. Malis



Bits 25-32: Message Type:

     Type 0: Regular Message  -  All  host-to-host  communication

          occurs  via  regular  messages, which have several sub-

          types, found in bits 77-80.  These sub-types are:

          0: Standard - The IMP uses its full message  and  error

               control facilities, and host blocking (see section

               2.4) may occur.

          1: Standard, short-blocking - See section 2.4.

          2: Uncontrolled, short-blocking - See section 2.4.

          3: Uncontrolled - The  IMP  will  perform  no  message-

               control  functions  for  this type of message, and

               network flow and congestion control  (see  section

               2.4)  may  cause  loss  of  the message.  Also see

               1822(3.6) and section 2.3.

          4-15: Unassigned.

     Type 1: Error Without Message ID - See 1822(3.3).

     Type 2: Host Going Down - see 1822(3.3).

     Type 3: Name Declaration Message (NDM)  -  This  message  is

          used by the host to declare which of its 1822L names is

          or is not effective (see section 2.2), or to  make  all

          of  its  names non-effective.  The first 16 bits of the

          data portion of the NDM message, following  the  leader

          and  any  padding,  contains  the  number of 1822L name




                             - 28 -




RFC 802                                           Andrew G. Malis



          entries contained in the message.  This is followed  by

          the 1822L name entries, each 32 bits long, of which the

          first 16 bits is a 1822L name and the  second  16  bits

          contains  either  of  the  integers  zero or one.  Zero

          indicates that the name should not  be  effective,  and

          one  indicates  that the name should be effective.  The

          IMP will reply with a NDM Reply  message  (see  section

          3.2)  indicating  which  of the names are now effective

          and which are not.  Pictorially, a NDM message has  the

          following   format  (including  the  leader,  which  is

          printed in hexadecimal):




























                             - 29 -




RFC 802                                           Andrew G. Malis






            1             16 17            32 33            48
           +----------------+----------------+----------------+
           |                |                |                |
           |      0D00      |      0003      |      0000      |
           |                |                |                |
           +----------------+----------------+----------------+
            49            64 65            80 81            96
           +----------------+----------------+----------------+
           |                |                |                |
           |      0000      |      0000      |      0000      |
           |                |                |                |
           +----------------+----------------+----------------+
            97           112 113          128 129          144
           +----------------+----------------+----------------+
           |                |                |                |
           |  # of entries  |  1822L name #1 |     0 or 1     |
           |                |                |                |
           +----------------+----------------+----------------+
           145           160 161          176
           +----------------+----------------+
           |                |                |
           |  1822L name #2 |     0 or 1     |       etc.
           |                |                |
           +----------------+----------------+

                  Figure 6. NDM Message Format



          An  NDM  with  zero  entries  will  cause  all  current

          effective names for the host to become non-effective.

     Type 4: NOP - This allows the IMP to  know  which  style  of

          leader  the  host wishes to use.  A 1822L NOP signifies

          that the host wishes to use 1822L leaders, and an  1822

          NOP signifies that the host wishes to use 1822 leaders.

          All of the other remarks concerning the NOP message  in




                             - 30 -




RFC 802                                           Andrew G. Malis



          1822(3.3)  still  hold.   The  host should always issue

          NOPs in groups of three to insure proper  reception  by

          the IMP.  Also see section 2.5 for a further discussion

          on the use of the NOP message.

     Type 8: Error with Message ID - see 1822(3.3).

     Types 5-7,9-255: Unassigned.


Bits 33-48: Source Host:

     This field contains one of the  source  host's  1822L  names

     (or,  alternatively,  the 1822L address of the host port the

     message  is  being  sent   over).    This   field   is   not

     automatically filled in by the IMP, as in the 1822 protocol,

     because the host may be known by several names and may  wish

     to use a particular name as the source of this message.  All

     messages from the same host need not use the  same  name  in

     this  field.   Each  source  name, when used, is checked for

     authorization, effectiveness, and actually belonging to this

     host.  Messages using names that do not satisfy all of these

     requirements will not be delivered, and will instead  result

     in  an  error  message being sent back into the source host.

     If the host places its 1822L  Address  in  this  field,  the

     address is checked to insure that it actually represents the

     host port where the message originated.  If the  message  is

     destined for an 1822 host on a non-C/30 IMP, this field MUST



                             - 31 -




RFC 802                                           Andrew G. Malis



     contain the source host's 1822L address  (see  Figure  4  in

     section 2.2).


Bits 49-64: Destination Host:

     This field  contains  the  1822L  name  or  address  of  the

     destination  host.   If it contains a name, the name will be

     checked for effectiveness, with an error message returned to

     the  source  host  if  the  name  is  not effective.  If the

     message is destined for an 1822 host on a non-C/30 IMP, this

     field MUST contain the destination host's 1822L address (see

     Figure 4 in section 2.2).


Bits 65-76: Message ID:

     This is a host-specified identification used in all  type  0

     and  type  8  messages, and is also used in type 2 messages.

     When used in type 0 messages, bits 65-72 are also  known  as