rfc802.txt

RFC 相关的技术文档

always authorized in this sense.


Once a host has been assigned one or more names, it  has  to  let

the  IMPs  know  where it is and what name(s) it is using.  There

are two cases to consider, one for 1822L hosts  and  another  for

1822  hosts.   The following discussion only pertains to hosts on

C/30 IMPs.


When an IMP sees an 1822L host come up on a host  port,  the  IMP

has  no way of knowing which host has just come up (several hosts

may share the same port, or one host may prefer to  be  known  by




                              - 9 -




RFC 802                                           Andrew G. Malis



different  names  at different times).  This requires the host to

let the IMP know what is happening before it  can  actually  send

and  receive messages.  This function is performed by a new host-

to-IMP message, the Name Declaration Message (NDM),  which  lists

the  names  that  the  host  would  like to be known by.  The IMP

checks its tables to see if each of the names is authorized,  and

sends an NDM Reply to the host saying which names in the list can

be used for sending and receiving messages (i.e., which names are

effective). A host can also use an NDM message to change its list

of effective addresses (it can add to and delete from  the  list)

at  any  time.  The only constraint on the host is that any names

it  wishes  to  use  can  become  effective  only  if  they   are

authorized.


In the second case, if a host comes up on a C/30  IMP  using  the

1822 protocol, the IMP automatically makes the first name the IMP

finds in its tables for that host become effective.   Thus,  even

though  the host is using the 1822 protocol, it can still receive

messages from 1822L hosts via its 1822L name.  Of course, it  can

also receive messages from an 1822L host via its 1822L address as

well.   (Remember,  the  distinction  between  1822L  names   and

addresses  is that the addresses correspond to physical locations

on  the  network,  while   the   names   are   strictly   logical

identifiers).   The  IMPs translate between the different leaders



                             - 10 -




RFC 802                                           Andrew G. Malis



and send the proper leader in each case (more on this below).


The third question above has by now already been answered.   When

an  1822L  host comes up, it uses the NDM message to tell the IMP

which host it is (which names it is known by).  Even if this is a

shared port, the IMP knows which host is currently connected.


Whenever a host goes down, its names  automatically  become  non-

effective.   When it comes back up, it has to make them effective

again.


Several hosts can share the same 1822L name.  If more than one of

these  hosts  is  up  at the same time, any messages sent to that

1822L name will be delivered to just one  of  the  hosts  sharing

that  name,  and  a RFNM will be returned as usual.  However, the

sending host will  not  receive  any  indication  of  which  host

received  the  message,  and subsequent messages to that name are

not guaranteed to be sent to the  same  host.   Typically,  hosts

providing  exactly  the  same  service could share the same 1822L

name in this manner.


Similarly, when a host is multi-homed, the same  1822L  name  may

refer  to  more  than  one  host  port (all connected to the same

host).  If the host is up on only one of those ports,  that  port

will  be  used for all messages addressed to it.  However, if the




                             - 11 -




RFC 802                                           Andrew G. Malis



host were up  on  more  than  one  port,  the  message  would  be

delivered  over  just  one  of  those ports, and the subnet would

choose which port to use.  This port selection could change  from

message  to  message.   If  a  host wanted to insure that certain

messages were delivered to it on specific ports,  these  messages

could  use  either  the  port's 1822L address or a specific 1822L

name that referred to that port alone.


Some further details are required on communications between  1822

and  1822L  hosts.   Obviously, when 1822 hosts converse, or when

1822L hosts converse, no conversions between leaders and  address

formats  are  required.   However,  this becomes more complicated

when 1822 and 1822L hosts converse with each other.


The   following   figure   illustrates   how   these   addressing

combinations  are  handled,  showing  how  each  type of host can

access every other type of host.  There are three types of hosts:

"1822  on  C/30"  signifies  an  1822 host that is on a C/30 IMP,

"1822L" signifies an 1822L host (on a C/30  IMP),  and  "1822  on

non-C/30"  signifies  a  host  on  an  non-C/30 IMP (which cannot

support the 1822L protocol).  The table entry shows the  protocol

and  host address format(s) that the source host can use to reach

the destination host.






                             - 12 -




RFC 802                                           Andrew G. Malis






                            Destination Host
  Source
  Host    | 1822 on C/30   | 1822L          | 1822 on non-C/30
  --------+----------------+----------------+-----------------
          |                |                |
  1822 on | 1822           | 1822           | 1822
  C/30    |                | (note 1)       |
          |                |                |
  --------+----------------+----------------+-----------------
          |                |                |
          | 1822L, using   | 1822L, using   | 1822L, using
  1822L   | 1822L name or  | 1822L name or  | 1822L address
          |address (note 2)| address        | only (note 2)
          |                |                |
  --------+----------------+----------------+-----------------
          |                |                |
  1822 on | 1822           | 1822           | 1822
  non-C/30|                | (note 1)       |
          |                |                |
  --------+----------------+----------------+-----------------

  Note 1: The message is presented  to  the  destination  host
          with  an 1822L leader containing the 1822L addresses
          of the source  and  destination  hosts.   If  either
          address  cannot be encoded as an 1822L address, then
          the message is not delivered and and  error  message
          is sent to the source host.

  Note 2: The message is presented  to  the  destination  host
          with  an  1822 leader containing the 1822 address of
          the source host.


     Figure 4. Communications between different host types












                             - 13 -




RFC 802                                           Andrew G. Malis



2.3  Uncontrolled Messages


Uncontrolled messages (see 1822(3.6)) present  a  unique  problem

for  the  1822L  protocol.  Uncontrolled messages use none of the

normal ordering and error-control mechanisms in the IMP,  and  do

not  use  the  normal  subnetwork  connection  facilities.   As a

result, uncontrolled messages need to carry all of their overhead

with  them, including source and destination addresses.  If 1822L

addresses  are  used  when  sending  an   uncontrolled   message,

additional information is now required by the subnetwork when the

message is transferred to the destination IMP.  This  means  that

less  host-to-host  data  can be contained in the message than is

possible between 1822 hosts.


Uncontrolled messages  that  are  sent  between  1822  hosts  may

contain  not  more  than 991 bits of data.  Uncontrolled messages

that are sent to and/or from 1822L hosts are limited to  32  bits

less,  or  not  more  than  959  bits.  Messages that exceed this

length will result in an error indication to the  host,  and  the

message  will  not  be sent.  This error indication represents an

enhancement to the previous level of service provided by the IMP,

which  would  simply  discard an overly long uncontrolled message

without notification.






                             - 14 -




RFC 802                                           Andrew G. Malis



Other enhancements that are  provided  for  uncontrolled  message

service  are  a  notification  to the host of any message-related

errors that are detected by the host's IMP when it  receives  the

message.   A  host  will  be  notified if an uncontrolled message

contains an error in the 1822L name specification,  such  as  the

name  not being authorized or effective, or if the remote host is

unreachable (which is  indicated  by  none  of  its  names  being

effective),  or  if  network  congestion  control  throttled  the

message before it left the source IMP.   The  host  will  not  be

notified  if  the  uncontrolled  message was lost for some reason

once it was transmitted by the source IMP.




2.4  The Short-Blocking Feature


The short-blocking feature of the 1822  and  1822L  protocols  is

designed  to  allow a host to present messages to the IMP without

causing the IMP to not accept further messages from the host  for

long amounts of time (up to 15 seconds).  It is a replacement for

the non-blocking host interface described in 1822(3.7), and  that

description should be ignored.










                             - 15 -




RFC 802                                           Andrew G. Malis



2.4.1  Host Blocking


Most commonly, when a source host submits a message  to  an  IMP,

the  IMP  immediately  processes that message and sends it on its

way to its destination host.  Sometimes, however, the IMP is  not

able  to  process  the message immediately.  Processing a message

requires a significant number of resources, and when the  network

is heavily loaded, there can sometimes be a long delay before the

necessary resources become available.  In  such  cases,  the  IMP

must  make  a decision as to what to do while it is attempting to

gather the resources.


One possibility is for the IMP to stop  accepting  messages  from

the  source  host  until  it has gathered the resources needed to

process the message just submitted.  This strategy  is  known  as

blocking  the  host,  and is basically the strategy that has been

used in the ARPANET up to the present.  When  a  host  submits  a

message  to  an  IMP, all further transmissions from that host to

that IMP are blocked until the message can be processed.


It is important to note, however, that not all  messages  require

the  same  set  of resources in order to be processed by the IMP.

The particular set of resources needed will depend on the message

type, the message length, and the destination host of the message

(see below).  Therefore, although it might take a  long  time  to



                             - 16 -




RFC 802                                           Andrew G. Malis



gather  the  resources needed to process some particular message,

it might take only a short time to gather the resources needed to

process  some  other  message.   This  fact exposes a significant

disadvantage in the strategy of blocking the host.  A host  which

is  blocked may have many other messages to submit which, if only

they could be submitted, could be processed immediately.   It  is

"unfair"  for  the IMP to refuse to accept these message until it

has gathered the resources for  some  other,  unrelated  message.

Why  should messages for which the IMP has plenty of resources be

delayed for an arbitrarily long amount of time just  because  the

IMP lacks the resources needed for some other message?


A simple way to alleviate the problem would be to place  a  limit

on  the  amount of time during which a host can be blocked.  This

amount  of  time  should  be  long  enough  so  that,   in   most

circumstances,  the  IMP  will  be  able  to gather the resources

needed to process the message within the given time period.   If,

however, the resources cannot be gathered in this period of time,

the IMP will flush the message, sending a  reply  to  the  source

host   indicating   that  the  message  was  not  processed,  and

specifying the reason that it could not be  processed.   However,

the  resource gathering process would continue.  The intention is

that the host  resubmit  the  message  in  a  short  time,  when,

hopefully,   the   resource   gathering   process  has  concluded



                             - 17 -




RFC 802                                           Andrew G. Malis



successfully.   In  the  meantime,  the  host  can  submit  other

messages,  which may be processed sooner.  This strategy does not

eliminate the phenomenon of host blocking, but  only  limits  the

time  during  which  a  host is blocked.  This shorter time limit

will generally fall somewhere in the range of 100 milliseconds to

2  seconds,  with  its value possibly depending on the reason for

the blocking.


Note, however, that there  is  a  disadvantage  to  having  short

blocking  times.  Let us say that the IMP accepts a message if it

has all the resources needed to process it.  The ARPANET provides

a  sequential  delivery  service,  whereby messages with the same

priority, source host, and destination host are delivered to  the

destination  host in the same order as they are accepted from the

source host.  With short blocking times, however,  the  order  in

which  the  IMP accepts messages from the source host need not be

the same as  the  order  in  which  the  source  host  originally

submitted  the messages.  Since the two data streams (one in each

direction) between the host and the IMP are not synchronized, the

host  may  not  receive the reply to a rejected message before it

submits subsequent messages of the same  priority  for  the  same

destination host.  If a subsequent message is accepted, the order

of acceptance differs from the order of original submission,  and

the ARPANET will not provide the same type of sequential delivery



                             - 18 -




RFC 802                                           Andrew G. Malis



that it has in the past.


Up to now, type 0 (regular)  messages  have  only  had  sub-types

available  to  request the standard blocking timeout.  The short-

blocking feature makes available new  sub-types  that  allow  the

host  to  request  messages to be short-blocking, i.e. only cause

the host to be blocked for a short amount of time if the  message

cannot be immediately processed.   See section 3.1 for a complete

list of the available sub-types.


If sequential delivery by the subnet is a strict requirement,  as

would  be  the  case  for  messages  produced  by NCP, the short-

blocking feature cannot be used.  For messages produced  by  TCP,

however,  the  use  of  the short-blocking feature is allowed and

recommended.




2.4.2  Reasons for Host Blockage


There are a number of reasons why a message could  cause  a  long

blockage  in  the  IMP,  which would result in the rejection of a

short-blocking message.  The IMP  signals  this  rejection  of  a

short-blocking message by using the Incomplete Transmission (Type

9) message, using the sub-type field to  indicate  which  of  the

above  reasons  caused the rejection of the message.  See section




                             - 19 -




RFC 802                                           Andrew G. Malis



3.2 for a summary of the Incomplete Transmission  message  and  a

complete  list of its sub-types.  The sub-types that apply to the

short-blocking feature are:


6.  Connection setup-delay: Although the IMP  presents  a  simple

    message-at-a-time  interface  to  the  host,  it  provides an

    internal  connection-oriented  (virtual   circuit)   service,

    except  in  the  case  of  uncontrolled messages (see section

    2.3).   Two  messages  are  considered  to  be  on  the  same

    connection  if they have the same source host (i.e., they are

    submitted to the same IMP over the same host interface),  the

    same priority, and the same destination host name or address.

    The subnet maintains internal connection set-up and tear-down

    procedures.   Connections  are set up as needed, and are torn

    down  only  after  a  period  of  inactivity.   Occasionally,

    network  congestion or resource shortage will cause a lengthy

    delay in connection set-up.  During this period, no  messages

    for  that  connection can be accepted, but other messages can

    be accepted.


7.  End-to-end flow  control:  For  every  message  that  a  host

    submits  to  an  IMP  (except  uncontrolled messages) the IMP

    eventually  returns  a  reply  to  the  host  indicating  the

    disposition  of  the  message.   Between  the  time  that the




                             - 20 -




RFC 802                                           Andrew G. Malis