Comments on the IMP/Host and Host/IMP Protocol changes
Vinton Cerf compares ARPANET host-IMP protocol changes with a proposed international packet header.
Cerf, V.G., "Comments on the IMP/Host and Host/IMP Protocol changes", RFC 696, DOI 10.17487/RFC0696, July 1975, <https://www.rfc-editor.org/info/rfc696>.
@misc{rfc696,
series = {Request for Comments},
number = 696,
howpublished = {RFC 696},
publisher = {RFC Editor},
doi = {10.17487/RFC0696},
url = {https://www.rfc-editor.org/info/rfc696},
author = {V.G. Cerf},
title = {{Comments on the IMP/Host and Host/IMP Protocol changes}},
pagetotal = 2,
year = 1975,
month = jul,
} RFC text
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.
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 ]
AI ELI5
On this page
§1Context: An International Header Proposal
Vinton Cerf writes in reference to RFCs 687, 690 and 692 on IMP/Host and Host/IMP protocol changes. He offers observations about a recommendation from working group 6.1 of the International Federation of Information Processing. At a May meeting at the NCC, the group voted to present CCITT with a recommendation for a standard packet (or datagram) header.
The header is meant to interface hosts to packet networks. It is not a Host-to-Host header and not an IMP-to-IMP header. Most of it is address space (96 bits), chosen to be compatible with the current maximum address space of the telephone system (14 digits).
An international group wanted every packet network to use the same kind of address label. This note says what the label would look like and how ARPANET might fit.
§2The Proposed Header Fields
The fields are: Local Network (4 bits, usable by a local network in any way it wants), Datagram Format (4 bits, which ARPANET could set to binary 1001 to stay compatible with the existing message leader), Packet Type Code (8 bits, usable for the HOST/IMP and IMP/HOST code) and Facilities (16 bits, not yet allocated; possibly for tracing, accounting and class of service, with perhaps 8 bits left to the originating or destination network).
Then Text Length (16 bits) counts the octets of text, excluding the fixed-length header. The 48-bit Destination Address could be split into network identifier (8 bits), host identifier (8 bits), IMP identifier (16 bits) and 16 reserved bits. The 48-bit Source Address would work similarly.
The label has boxes for where the packet is going, where it came from, how long it is, and some extras. Each box has a set size.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
LOCAL-NETWORK | Local Network | 4 bits | Free for the local network to use. | |
DATAGRAM-FORMAT | Datagram Format | 4 bits | ARPANET could use binary 1001. | |
PACKET-TYPE | Packet Type Code | 1 byte | Could carry the HOST/IMP and IMP/HOST code. | |
FACILITIES | Facilities | 2 bytes | Not yet allocated. | |
TEXT-LENGTH | Text Length | 2 bytes | Octets of text, not counting the header. | |
DESTINATION | Destination Address | 6 bytes | Network, host and IMP identifiers plus reserved bits. | |
SOURCE | Source Address | 6 bytes | Used like the destination address. |
§3Fitting It With the Host-to-Host Header
The resulting packet header is 144 bits long. Adding the present 40-bit Host-to-Host header gives 184 bits, which Cerf calls not very pleasant. A temporary fix, until a new NCP design, would squeeze out the reserved 16-bit fields in the two addresses, giving 32 bits to carry the byte size and byte count.
Other options are to use the length field and a facilities flag to indicate byte size and count, or to add a dummy byte after the 144th bit, followed by the 40 bits of NCP header. That totals 192 bits, a number divisible by 12, 16, 24, 32 and 48. The first two ideas need substantial changes to existing NCP programs and are probably not very palatable.
The new label plus the old label do not add up to a nice round size. The note suggests a few ways to trim or pad until the pieces fit.
§4Bit Lengths for Text
On the proposed text length field, Cerf notes that bit lengths are the most flexible. He says it seems reasonable to admit that nearly all data transmission is done in 8-bit quantities, which would make bit lengths an unnecessary luxury. He adds that this is a weak argument when 36-bit and 32-bit machines must interface.
Most computers count in groups of eight bits, but some use other sizes, so counting in single bits is still the safest choice.