Comments on the IMP/Host and Host/IMP Protocol changes

V.G. Cerf

doi:10.17487/RFC0696

[RFC Home] [TEXT|PDF|PDF|HTML] [Tracker] [IPR] [Info page]

This is a modified version of the Internet RFC suitable for machine-translating. Original version is available here: RFC696

UNKNOWN

Network Working Group                                            V. Cerf
Request for Comments: 696                            Stanford University
NIC: 32962                                                     July 1975

Comments on IMP/HOST and HOST/IMP Protocol Changes

With reference to RFC's 687, 690, and 692 (NIC's 32564, 32699, and 32734, respectively) by D.C. Walden, J. Postel, and S. Wolfe (respectively), I would like to offer some observations relative to current international standards recommendations from working group 6.1 of the International Federation of Information Processing. In a meeting held last May at the NCC, this working group voted to present a recommendation to CCITT (International Consultative Committee on Telephony and Telegraphy of the International Telegraphics Union) for a standard packet (or DATAGRAM) header.

The proposed packet header format is meant to interface hosts to packet networks. It is not a header for Host-to-Host protocol, nor is it an IMP-to-IMP header. The bulk of the header is taken up with addressing space(96 bits!) since this will be compatible with the current maximum address space of the telephone system (14 digits).

LOCAL NETWORK FIELD - 4 bits

This field allows local networks to operate easily on multiple formats, since the 4 bits can be used in any fashion desired by the local network.

DATAGRAM FORMAT - 4 bits

This field could be used by ARPANET to contain "1001" binary, so as to maintain backward compatibility with the existing message leader format.

PACKET TYPE CODE - 8 bits

This could be used for the HOST/IMP and IMP/HOST code.

FACILITIES - 16 bits

These bits have not yet been specifically allocated. Some will no doubt be for international services (e.g., tracing at gateways between networks, accounting, class of service). It was the feeling of WG 6.1 members that some of these bits (e.g., 8) might be allocated to the originating network (or destination network) for its own use.

Cerf                                                            [Page 1]


RFC 696    Comments on IMP/HOST and HOST/IMP Protocol Changes  July 1975

TEXT LENGTH - 16 bits

These bits count the number of octets in the text of the packet, not including octets in the header (which is fixed in length for any particular format).

DESTINATION ADDRESS - 48 bits [1]

These bits could be allocated in the following way: Destination Network Identifier - 8 bits; Destination Host Identifier - 8 bits; Destination IMP identifier - 16 bits; Reserved- 16 bits.

SOURCE ADDRESS - 48 bits

These bits would be used in a fashion similar to the destination address bits.

The resulting packet is 144 bits long and adding the present 40-bit Host-to-Host header results in a total of 184 bits, which is not very pleasant. A temporary fix (until we can introduce a new NCP design) might be to squeeze out the reserved 16-bit fields in the source and destination address fields, giving 32 bits to carry the byte size and byte count information for the present Host/Host protocol. Alternatively, the length field of the packet header and one of the facilities flags (or a whole field) could be used to indicate byte size and byte count. Either idea would require some fairly substantial modification of existing NCP programs, so is probably not very palatable.

Another alternative would be to add a dummy byte after the 144th bit of header, followed by 40 bits of NCP header, giving a total length of message leader and NCP header of 192 bits, a number divisible by 12, 16, 24, 32, 48.

With respect to the proposed text length field, although bit lengths are the most flexible, it seems reasonable to admit that nearly all data transmission is done in 8-bit quantities, and therefore that bit lengths are, in fact, an unnecessary luxury. This is a weak argument when 36-bit and 32-bit machines must interface.

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 11/99 ]

Cerf [Page 2]

Translate documents to 日本語, svenska, Nederlands, Deutsch, français, русский, italiano, español, Tiếng Việt, polski, português, 中文, українська, català, norsk, فارسی, suomi, Bahasa Indonesia, العربية, čeština, 한국어, Bahasa Melayu, magyar, română, српски and other languages.