Документ взят из кэша поисковой машины. Адрес оригинального документа : http://mirror.msu.net/pub/rfc-editor/rfc-ed-all/ien/ien82.txt Дата изменения: Mon Jun 25 22:47:34 2001 Дата индексирования: Tue Oct 2 09:14:51 2012 Кодировка:

M.I.T. Lab. for Computer Science Network Implementation Note No. 5

February 15, 1979
IEN-82



LCS Net Address Format

Noel Chiappa
David Clark
David Reed







This note defines the current format of addresses in the LCS
Local Net and their translation into LCS hardware headers as well
as InterNet addresses and CHAOS Net addresses.




























_________________________________________________________________
This note is an informal working paper of the M.I.T. Laboratory
for Computer Science. It should not be reproduced without the
author's permission, and it should not be cited in other
publications.
 February 15, 1979


This note defines the current format of addresses in the LCS
Local Net and their translation into LCSNet hardware headers as
well as CHAOS addresses and InterNet addresses. Address and
protocol numbers specific to the LCSNet are also temporaily
defined in this note.


Note that the proposal stated in this is not final, but is
motivated by other considerations. The LNI as currently designed
contains sophisticated name matching facilities of unknown worth.
It is not yet clear whether this hardware is useful or not, but
we felt that we should at least explore the possibilities, and
have thus designed the protocol to take maximum advantage of the
hardware's features. Depending on the results of our preliminary
work with the name matching hardware, we may or may not keep< it
in future versions of the LNI.


The basic hardware format of a LCS-LN packet is as follows:


DPNM 31 0
|________________________________|

DPN 31 0
|________________________________|

OPN 31 0
|________________________________|

LEN 15 0
|________________|

DATA 8n-1 0
|________________|



(Unless others stated, all bit numbers are in decimal and
all others are in octal.)


The DPNM, DPN, OPN and LEN fields are all defined by the
hardware. The DATA field contains LEN bytes of data. The DPNM
(Destination Process Name Mask) together with the DPN
(Destination Process Name) specify the destination address, and
the OPN (Originating Process Name) is the sender's address. This
field is actually unused by the hardware, but is reserved for
future use. The workings of the DPNM and DPN are as follows: in
every LNI there is an array of sofware loadable names (the Name
Table, NT), each with a DPNM and a DPN. The name matching
algorithm is a follows: for each bit in the name, if the two bits
in the DPN's are equivalent or if either DPNM bit is on, then
 February 15, 1979


that bit matched. If all the bits matched, then the name matched.


The basic format of the headers (imposed by the sotware) is
as follows:


DPNM 31 Type 23 0
|________|________________________|

DPN 31 Rsd 23 0
|________|________________________|

OPN 31 Reserved 0
|________________________________|

LEN 15 0
|________________|

DATA 8n-1 0
|________________|


"Rsd" stands for "Reserved" and "Type" is the Local Type. As a
general rule the value of 0 for any field is reserved for fixing
catastrophes not yet visible to the eye. The following
conventions are to be used in assigning type numbers: types 1
through 077 have a common address format, specified below, types
100 through 277 are reserved, and types 301 through 377 are
available for (experimental) protocols which may use the next 24
bits of address as they see fit.


The intention of the above is that bridges be able to easily
recognize, via the top bit(s) whether or not the address field
fits a common format. Clearly there are enormous advantages, in
the building of bridges and other areas, where it is desirable to
have a common address format, but it is obviously also desirable
not to hamstring the development of other very different
protocols (such as a distributed process system or a distributed
file system) which would fit poorly into the classical addressing
system.


For types that use the common address format, the address
format is:


00 Type SNet Rsd Host
31 29 23 15 7 0
|__|______|________|________|________|
 February 15, 1979


The field marked "Rsd" is reserved for future use. It is intended
that it be used for address expansion should it become necessary,
but it may be used for whatever appears appropiate, such as a
"Flag" field.


SubNet numbers and Host Numbers (per SubNet) are currently
being assigned in common with the AI Lab's CHAOS Net in an
attempt to maintain an MIT wide addressing unity. The main
repository for these numbers is in the online file
AI:SYSENG;HOSTS > on MIT-AI. numbers specific to our net are:


Number SubNet

0 Reserved
1-7 Unassigned
10 LCS LN
11-377 Unassigned

Subnet 10
Number Host

0 Reserved
1 - 7 Unassigned
10 CSR 11/40
11 DSSR 11/70
12 - 17 Unassigned
20 VAX
21 - 377 Unassigned


It is not intended that this note be the official source for host
and subnet numbers; rather, there will be an online database
which at the moment is the specified ITS file.


The assigned protocol types are:


Type Use

0 Reserved
1 InterNet Datagram (Internal)
2 CHAOS Packet
3-77 Unassigned
100-277 Reserved
300 Reserved
301 InterNet Datagram (Outbound)
302-377 Unassigned
 February 15, 1979


In all cases the specified header is followed immediately by
a packet of the specified type as defined in the appropriate
reference. [1,2] At the moment, the format of outbound InterNet
packets is as follows:


11 000 Rsd Ext Net
31 29 23 7 0
|__|______|________________|________|


where "Ext Net" is the major net number of the destination. In
internal InterNet packets, the mapping from InterNet Headers to
MIT addresses is simple; the 24 bits of "Address" after "Net
Number" in the InterNet header have the same format as the
adddress of a common address format packet, and are copied
directly into the header. In the future, some attempt may be made
to support variable address format addresses on inbound packets.
 February 15, 1979


References


[1] Postel, Jonathan B., "InterNetwork Protocol Specification,
Version IV," Information Sciences Institute, University of
Southern California, IEN 54, September 1978.

[2] Greenblatt, Richard G., and Moon, David, "CHAOS Protocol
Specification," Artificial Intelligence Laboratory, M.I.T., 1978.