rfc802.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 2,673 行 · 第 1/5 页

               +--------------------------------+

                  Figure 2. 1822L Name Format



The 1822L names are just 16-bit  unsigned  numbers,  except  that

bits  1  and  2 are not both zeros (see below).  This allows over

49,000 hosts to be specified.


1822 addresses cannot be used in 1822L leaders, but there may  be

a  requirement for an 1822L host to be able to address a specific

physical host port or IMP fake host.  1822L  addresses  are  used

for  this  function.   1822L addresses form a subset of the 1822L

name space, and have both bits 1 and 2 off.



               1   2  3          8 9             16
             +---+---+------------+----------------+
             |   |   |            |                |
             | 0 | 0 |   host #   |   IMP number   |
             |   |   |            |                |
             +---+---+------------+----------------+

                 Figure 3. 1822L Address Format








                              - 7 -




RFC 802                                           Andrew G. Malis



This format gives 1822L hosts the  ability  to  directly  address

hosts  0-59  at  IMPs 1-255 (IMP 0 does not exist).  Host numbers

60-63 are reserved for addressing the four  fake  hosts  at  each

IMP.




2.2  Name Authorization and Effectiveness


Every host on a C/30 IMP, regardless of whether it is  using  the

1822 or 1822L protocol to access the network, will be assigned at

least one 1822L name (logical address).  Other 1822L  hosts  will

use  this name to address the host, wherever it may be physically

located.  Because of the implementation constraints mentioned  in

the introduction, hosts on non-C/30 IMPs cannot be assigned 1822L

names.  To circumvent this restriction, however, 1822L hosts  can

use  1822L addresses to access all other hosts on the network, no

matter where they reside.


At this point, several questions  arise:   How  are  these  names

assigned,  how  do  they  become  known  to  the  IMPs  (so  that

translations to physical addresses can be made), and how  do  the

IMPs know which host is currently using a shared port?  To answer

each question in order:







                              - 8 -




RFC 802                                           Andrew G. Malis



Names are assigned by a central network administrator.  When each

name  is  created, it is assigned to a host (or a group of hosts)

at one or more specific host ports.  The host(s) are  allowed  to

reside at those specific host ports, and nowhere else.  If a host

moves, it will keep the same name, but the administrator  has  to

update  the  central  database  to  reflect  the  new  host port.

Changes to this database are  distributed  to  the  IMPs  by  the

Network  Operations  Center  (NOC) at BBN.  For a while, the host

may be allowed to reside at either of (or both) the new  and  old

ports.   Once  the  correspondence between a name and one or more

hosts ports where it may be used has been made  official  by  the

administrator,   that  name  is  said  to  be  authorized.  1822L

addresses, which actually  refer  to  physical  host  ports,  are

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.