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.