RFC 802
ARPANET 1822L Host Access Protocol
RFC 802: The ARPANET 1822L Host Access Protocol ✨
Author: Andrew G. Malis (Netmail: malis@bbn-unix) 🎀 Organization: Bolt Beranek and Newman Inc. 🏢 Date: November 1981 📅
Table of Contents 📚
1 INTRODUCTION.......................................... 1
2 THE ARPANET 1822L HOST ACCESS PROTOCOL................ 4
2.1 Addresses and Names................................. 6
2.2 Name Authorization and Effectiveness................ 8
2.3 Uncontrolled Messages.............................. 14
2.4 The Short-Blocking Feature......................... 15
2.4.1 Host Blocking.................................... 16
2.4.2 Reasons for Host Blockage........................ 19
2.5 Establishing Host-IMP Communications............... 22
3 1822L LEADER FORMATS................................. 25
3.1 Host-to-IMP 1822L Leader Format.................... 26
3.2 IMP-to-Host 1822L Leader Format.................... 34
4 REFERENCES........................................... 42Figures 🖼️
1822 Address Format....................................... 6
1822L Name Format......................................... 7
1822L Address Format...................................... 7
Communications between different host types.............. 13
Host-to-IMP 1822L Leader Format.......................... 27
NDM Message Format....................................... 30
IMP-to-Host 1822L Leader Format.......................... 351. INTRODUCTION 🎀
Okay bestie, so this doc proposes two major changes to the current ARPANET host access protocol 🦋. Change number one: hosts can use logical addressing (host addresses that don't depend on where they physically sit on the ARPANET) to talk to each other ✨. Change number two: a host can shorten how long its IMP is allowed to block it after it hands over a message to the network. Right now the IMP can block further input from a host for up to 15 seconds 😭.
The new protocol is the ARPANET 1822L (for Logical) Host Access Protocol 💜. It's an addition to the current ARPANET 1822 Host Access Protocol, which is described in sections 3.3 and 3.4 of BBN Report 1822 [1]. Even though 1822L uses different Host-IMP leaders than 1822, hosts using either protocol can still readily communicate with each other, because the IMPs handle the translation automatically 🫶.
The new option for shortening the host blocking timeout is called the short-blocking feature 🌸. It replaces the non-blocking host interface described in section 3.7 of Report 1822. This feature will be available to all hosts on C/30 IMPs (see the next paragraph), regardless of whether they use the 1822 or 1822L protocol 💅.
There is one major restriction to the new capabilities being described. ⚠️ Both the 1822L protocol and the short-blocking feature will be implemented on C/30 IMPs only, so they'll only be useable by hosts connected to C/30 IMPs. The Honeywell and Pluribus IMPs don't have sufficient memory to hold the new programs and tables 💀. This restriction also means that logical addressing cannot be used to address a host on a non-C/30 IMP. However, the ARPANET will shortly be completely converted to C/30 IMPs, and at that time this restriction will no longer be a problem 🎉.
I will try to keep my terminology consistent with that used in Report 1822, and will define new terms when they are first used. Of course, familiarity with Report 1822 (section 3 in particular) is assumed 📖.
This document makes many references to Report 1822. As a convenient abbreviation, I will use "see 1822(x)" instead of "please refer to Report 1822, section x, for further details" 🙈.
This document is a proposal, not a description of an implemented system. Thus, described features are subject to change based upon responses to this document and restrictions that become evident during implementation. However, any such changes are expected to be minor. A new RFC will be made available once the implementation is complete, containing the actual as-implemented description 🧚.
Finally, I would like to thank Dr. Eric C. Rosen, who wrote most of section 2.4, and James G. Herman, Dr. Paul J. Santos Jr., John F. Haverty, and Robert M. Hinden, all of BBN, who contributed many of the ideas found herein 💖.
2. THE ARPANET 1822L HOST ACCESS PROTOCOL 👑
The ARPANET 1822L Host Access Protocol replaces the ARPANET 1822 Host Access Protocol described in Report 1822, sections 3.3 and 3.4. It allows a host to use logical addressing to communicate with other hosts on the ARPANET 🦋. Basically, logical addressing lets hosts refer to each other using an 1822L name (see section 2.1), which is independent of a host's physical location in the network. IEN 183 (also published as BBN Report 4473) [2] gives the use of logical addressing considerable justification. Among the advantages it cites are:
- The ability to refer to each host on the network by a name independent of its location on the network. 📍
- Allowing different hosts to share the same host port on a time-division basis. ⏰
- Allowing a host to use multi-homing (where a single host uses more than one port to communicate with the network). 🌈
- And allowing several hosts that provide the same service to share the same name. 🫶
The main differences between the 1822 and 1822L protocols are the format of the leaders that are used to introduce messages between a host and an IMP, and the specification in those leaders of the source and/or destination host(s) ✨. Hosts have the choice of using the 1822 or the 1822L protocol. When a host comes up on an IMP, it declares itself to be an 1822 host or an 1822L host host by the type of NOP message (see section 3.1) it uses. Once up, hosts can switch from one protocol to the other by issuing an appropriate NOP. Hosts that do not use the 1822L protocol will still be addressable by and can communicate with hosts that do, and vice-versa 💅.
Another difference between the two protocols is that the 1822 leaders are symmetric, while the 1822L leaders are not. The term symmetric means that in the 1822 protocol, the exact same leader format is used for messages in both directions between the hosts and IMPs. For example, a leader sent from a host over a cable that was looped back onto itself (via a looping plug or faulty hardware) would arrive back at the host and appear to be a legal message from a real host (the destination host of the original message) 😱. In contrast, the 1822L headers are not symmetric, and a host can detect if the connection to its IMP is looped by receiving a message with the wrong leader format. This allows the host to take appropriate action upon detection of the loop 🔥.
2.1. Addresses and Names 🏷️
The 1822 protocol defines one form of host specification, and the 1822L protocol defines two additional ways to identify network hosts. These three forms are 1822 addresses, 1822L names, and 1822L addresses 💜.
1822 addresses are the 24-bit host addresses found in 1822 leaders. They have the following format:
1 8 9 24
+----------------+---------------------------------+
| | |
| Host number | IMP number |
| | |
+----------------+---------------------------------+
Figure 1. 1822 Address FormatThese fields are quite large, and the ARPANET will never use more than a fraction of the available address space 🌍. 1822 addresses are used in 1822 leaders only.
1822L names are 16-bit unsigned numbers that serve as a logical identifier for one or more hosts. 1822L names have a much simpler format 🧸:
1 16
+--------------------------------+
| |
| 1822L name |
| |
+--------------------------------+
Figure 2. 1822L Name FormatThe 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 FormatThis 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:
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 think about: one for 1822L hosts and one for 1822 hosts. This bit only applies to hosts on C/30 IMPs, bestie 🎀
When an IMP sees an 1822L host pop up on a host port, the IMP has no clue which host just showed up 🙈. Several hosts might share the same port, or one host might want to be known by different names at different times. So the host has to tell the IMP what's going on before it can actually send and receive messages 💌. This is handled by a brand new host-to-IMP message called the Name Declaration Message (NDM), which lists the names the host would like to be known by ✨. The IMP checks its tables to see whether each name is authorized, then sends back an NDM Reply saying which names on the list can be used for sending and receiving. Those are the effective names 💖. A host can also send an NDM any time to change its list of effective names, adding or deleting as needed 🦋. The only rule for the host is that a name can only become effective if it's authorized. No authorization, no effective, periodt 💅.
Now the second case. If a host comes up on a C/30 IMP using the 1822 protocol, the IMP automatically makes the first name it finds in its tables for that host effective 🌸. So even though the host is speaking 1822, it can still get messages from 1822L hosts through its 1822L name. It can also receive messages from an 1822L host through its 1822L address, of course 🧚. (Quick reminder: 1822L names and addresses are different things. Addresses correspond to physical locations on the network, while names are strictly logical identifiers 🫶.) The IMPs translate between the different leaders and send the right leader in each case. More on that below 👑.
The third question from up top has already been answered 💅. When an 1822L host comes up, it uses the NDM message to tell the IMP which host it is, meaning which names it's known by. Even on a shared port, the IMP knows exactly 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 them is up at the same time, any message sent to that name gets delivered to just one of the hosts sharing it, and a RFNM comes back as usual. The sending host won't get any indication of which host received the message, and later messages to that name are not guaranteed to go to the same host either 🙈. This is typically used by hosts providing exactly the same service 🍓.
Same deal 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 gets used for every message addressed to it 💖. But if it's up on more than one port, the message is delivered over just one of them, and the subnet picks which one 🌈. That choice can change from message to message 😭. If a host wants certain messages delivered on specific ports, those messages can use either the port's 1822L address or a specific 1822L name that refers to that port alone 🎀.
Some extra details about communication between 1822 and 1822L hosts 🫶. When 1822 hosts talk to each other, or when 1822L hosts talk to each other, no conversion between leaders and address formats is needed, easy. But it gets more complicated when 1822 and 1822L hosts talk to each other 🌸.
The figure below shows how these addressing combinations work, and how each type of host can reach every other type 🧚. There are three types of hosts: "1822 on C/30" means an 1822 host on a C/30 IMP, "1822L" means an 1822L host (on a C/30 IMP), and "1822 on non-C/30" means a host on a non-C/30 IMP (which can't support the 1822L protocol) 💜. The table entry shows the protocol and host address format(s) the source host can use to reach the destination host 👑.
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
2.3. Uncontrolled Messages
Uncontrolled messages (see 1822(3.6)) cause a special headache for the 1822L protocol 😭. They don't use any of the IMP's normal ordering and error-control mechanisms, and they don't use the normal subnetwork connection facilities either 💀. Because of that, uncontrolled messages have to carry all of their overhead with them, including source and destination addresses 🎀. If 1822L addresses are used when sending an uncontrolled message, the subnetwork needs extra information when the message is passed to the destination IMP 🧚. That means less host-to-host data fits in the message than would fit between 1822 hosts 🫶.
Uncontrolled messages sent between 1822 hosts may contain not more than 991 bits of data 💖. Uncontrolled messages sent to and/or from 1822L hosts are limited to 32 bits less, so not more than 959 bits 🌸. If a message is too long, the host gets an error indication and the message isn't sent 🙅♀️. This error indication is a glow-up from the previous service, where the IMP would just quietly toss an overly long uncontrolled message without telling anyone ✨.
Uncontrolled message service has a few more upgrades 👑. The host gets notified about message-related errors that the host's IMP detects when it receives the message 🔥. A host will be notified if an uncontrolled message has an error in the 1822L name specification, such as a name that isn't authorized or effective 🙈. It also gets notified if the remote host is unreachable (which shows up as 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 gets lost for some reason after the source IMP already transmitted it 😭.
2.4. The Short-Blocking Feature
The short-blocking feature of the 1822 and 1822L protocols is designed to let a host hand messages to the IMP without making the IMP refuse further messages from that host for long stretches (up to 15 seconds) ⭐. It replaces the non-blocking host interface described in 1822(3.7), so ignore that description 🙅♀️.
2.4.1. Host Blocking
Usually, when a source host submits a message to an IMP, the IMP processes it right away and sends it on its way to the destination host ✨. Sometimes, though, the IMP can't process the message immediately 😩. Processing a message takes a serious amount of resources, and when the network is heavily loaded, there can be a long wait before the resources free up 🌧️. In those moments, the IMP has to decide what to do while it's trying to gather the resources 🤔.
One option is for the IMP to stop accepting messages from the source host until it has gathered the resources needed to process the message just submitted 🙃. This is called blocking the host, and it's basically the strategy the ARPANET has used up to now 🛑. When a host submits a message to an IMP, all further transmissions from that host to that IMP are blocked until the message can be processed 🔒.
Here's the tea though: not all messages need the same resources to be processed 🍵. The exact set depends on the message type, the message length, and the destination host (see below) 📦. So one message might take a long time to gather resources for, while another only takes a short time 🏃♀️. This exposes a big downside to blocking the host 😤. A blocked host might have lots of other messages that could be processed right away if only they could be submitted 💭. It's "unfair" for the IMP to refuse those messages until it has gathered resources for some other, unrelated message 🙅♀️. Why should messages the IMP has plenty of resources for get stuck for an arbitrarily long time just because it's short on resources for a different message? 🥺
A simple fix would be to put a limit on how long a host can be blocked ⏱️. The limit should be long enough that, in most circumstances, the IMP can gather the resources needed to process the message within that time 💪. But if the resources can't be gathered in that time, the IMP flushes the message, sends a reply to the source host saying the message wasn't processed, and gives the reason it couldn't be processed 📨. The resource gathering keeps going in the background though 🔄. The idea is that the host resubmits the message shortly, when, hopefully, the resource gathering has finished successfully 🤞. In the meantime, the host can submit other messages, which might get processed sooner 🏎️. This strategy does not
eliminate the phenomenon of host blocking, okay, but it only limits how long a host can get stuck 🫶 The wait is generally somewhere between 100 milliseconds and 2 seconds 🦋 and the exact number might depend on why the host got blocked in the first place ⏱️
Now here's the tea 🍵 short blocking comes with a catch. Say the IMP accepts a message whenever it has all the resources it needs to process it. The ARPANET has a sequential delivery service, which means messages with the same priority, source host, and destination host get delivered to the destination host in the same order they were accepted from the source host ✨ With really short blocking times, though, the order the IMP accepts messages from the source host doesn't have to match the order the source host originally submitted them 😭 The two data streams between the host and the IMP (one in each direction) aren't synchronized, so the host might not get the reply to a rejected message before it submits more messages with the same priority to the same destination host 💀 If one of those later messages gets accepted, the acceptance order is now different from the submission order, and the ARPANET won't give you that same sequential delivery it used to 🙈
Okay, bestie, next up are the sub-types 💅 Up until now, type 0 (regular) messages only had sub-types for requesting the standard blocking timeout. The short-blocking feature adds new sub-types that let the host ask for a message to be short-blocking, meaning the host only gets blocked for a short time if the message can't be processed right away 🌸 See section 3.1 for the full list of available sub-types 🎀
Here's the important part 💖 If sequential delivery by the subnet is a strict requirement (like for messages made by NCP), the short-blocking feature cannot be used ⚠️ For messages made by TCP, though, using short-blocking is allowed and recommended 🫶
2.4.2. Reasons for Host Blockage 🦋
There are a bunch of reasons a message could cause a long blockage in the IMP, which would then get a short-blocking message rejected 😤 The IMP signals that rejection with the Incomplete Transmission (Type 9) message, and it uses the sub-type field to say which of the reasons above caused the rejection ✨ See section 3.2 for a summary of the Incomplete Transmission message and a full list of its sub-types 🧚 The sub-types that matter for short-blocking are:
- Connection setup-delay: Even though the IMP gives the host a simple message-at-a-time interface, it provides an internal connection-oriented (virtual circuit) service, except for uncontrolled messages (see section 2.3) 🌈 Two messages count as being on the same connection if they have the same source host (meaning they're submitted to the same IMP over the same host interface), the same priority, and the same destination host name or address 💜 The subnet handles the internal connection set-up and tear-down procedures. Connections get set up as needed and only get torn down after a period of inactivity 😴 Sometimes network congestion or a resource shortage causes a lengthy delay in connection set-up. During that time, no messages for that connection can be accepted, but messages for other connections still can 🫶
- End-to-end flow control: For every message a host submits to an IMP (except uncontrolled messages), the IMP eventually sends back a reply telling the host what happened to the message 📬 Between the moment the message is submitted and the moment the host gets the reply, the message is called outstanding 🦋 The ARPANET only allows eight outstanding messages on any given connection 🙅♀️ If there are eight outstanding messages on a connection and a ninth is submitted, it cannot be accepted 😭 If a message gets refused because its connection is blocked by flow control, messages on other connections can still be accepted ✨
End-to-end flow control is the most common cause of host blocking in the ARPANET right now 👑
- Destination IMP buffer space shortage: If the host submits a message of more than 1008 bits (not counting the 96-bit leader), buffer space at the destination IMP has to be reserved before the message can be accepted 🍓 Buffer space at the destination IMP is always reserved on a per-connection basis 💅 If the destination IMP is heavily loaded, there might be a long wait for that buffer space, and this is another common cause of blocking on today's ARPANET 🥺 Messages get rejected for this reason based on their length and connection, so messages of 1008 or fewer bits, or messages for other connections, may still be acceptable 🎀
- Congestion control: A message might be refused for congestion control reasons if the path through the intermediate IMPs and lines to the destination IMP is too heavily loaded to take on any more traffic 🚦 Messages to other destinations may still be acceptable though 💖
- Local resource shortage: Sometimes the source IMP itself is running low on buffer space, table entries, or some other resource it needs to accept a message 📉 Unlike the other rejection reasons, this shortage affects all messages equally, except uncontrolled messages 😤 The message's size or connection doesn't matter here 💀
The short-blocking feature is available to all hosts on C/30 IMPs, whether they use the 1822 or 1822L protocol, through Type 0, sub-type 1 and 2 messages 🧚 A host using these sub-types should be prepared to correctly handle Incomplete Transmission messages from the IMP 🫶
2.5. Establishing Host-IMP Communications 🌸
When a host comes up on an IMP, or after there's been a break in communications between the host and its IMP (see 1822(3.2)), the orderly flow of messages between the host and the IMP needs to be properly (re)established 🔄 This lets the IMP and host recover from pretty much any failure on either side or in their communications path, including a break in the middle of a message 🛠️
The first messages a host should send to its IMP are three NOP messages 🎀 Three messages are required to ensure that at least one message gets read properly by the IMP (the first NOP could be stuck onto a previous message if communications had been broken mid-stream, and the third provides redundancy for the second) ✨ These NOPs do a few jobs at once: they synchronize the IMP with the host, they tell the IMP how much padding the host needs between the message leader and its body, and they tell the IMP whether the host will be using 1822 or 1822L leaders 💜
Similarly, the IMP will send three NOPs to the host when it detects that the host has come up 🧚 Actually, the IMP sends six NOPs, alternating three 1822 NOPs with three 1822L NOPs 😭 That way the host sees three NOPs no matter which protocol it's using 🙌 The NOPs are followed by two Interface Reset messages, one of each style 🦋 If the IMP receives a NOP from the host while this sequence is happening, the IMP will only send the rest of the NOPs and the Interface Reset in the proper style 💅 The 1822 NOPs contain the 1822 address of the host interface, and the 1822L NOPs contain the corresponding 1822L address 🍓
Once the IMP and the host have sent each other all of the above messages, regular communications can start 🎉 See 1822(3.2) for more details about the ready line, host tardiness, and other issues 🌈
3. 1822L LEADER FORMATS ✨
The following sections describe the formats of the leaders that come before messages between an 1822L host and its IMP 💖 They were designed to be as compatible with the 1822 leaders as possible 🫶 The second, fifth, and sixth words are identical in both leaders, and all of the existing functionality of the 1822 leaders has been kept 👑 The first difference you'll notice is in the first word 👀 The 1822 New Format Flag is now also used to identify the two types of 1822L leaders, and the Handling Type has moved to the second byte 🎀 The third and fourth words contain the Source and Destination 1822L Name, respectively 🧚
3.1. Host-to-IMP 1822L Leader Format 💜
1 4 5 8 9 16
+--------+--------+----------------+
| | 1822L | |
| Unused | H2I | Handling Type |
| | Flag | |
+--------+--------+----------------+
17 20 21 22 24 25 32
+--------+-+------+----------------+
| |T|Leader| |
| Unused |R|Flags | Message Type |
| |C| | |
+--------+-+------+----------------+
33 48
+----------------------------------+
| |
| Source Host |
| |
+----------------------------------+
49 64
+----------------------------------+
| |
| Destination Host |
| |
+----------------------------------+
65 76 77 80
+-------------------------+--------+
| | |
| Message ID |Sub-type|
| | |
+-------------------------+--------+
81 96
+----------------------------------+
| |
| Unused |
| |
+----------------------------------+
Figure 5. Host-to-IMP 1822L Leader Format- Bits 1-4: Unused, must be set to zero. 🫧
- Bits 5-8: 1822L Host-to-IMP Flag: This field is set to decimal 13 (1101 in binary). 🎀
- Bits 9-16: Handling Type: This field is bit-coded to indicate the transmission characteristics of the connection the host wants. See 1822(3.3). 💅
- Bit 9: Priority Bit: Messages with this bit on will be treated as priority messages. 👑
- Bits 10-16: Unused, must be zero. 🫧
- Bits 17-20: Unused, must be zero. 🫧
- Bit 21: Trace Bit: If equal to one, this message is designated for tracing as it proceeds through the network. See 1822(5.5). 🔍
okay that's the first chunk of the leader, and it's already giving detailed vibes 🦋
Bits 22-24: Leader Flags 🎀
Bit 22 is a flag that's available for use by the destination host. For how it gets used by the IMP's TTY fake host, check out 1822(3.3) 💅
- Bits 23-24 are reserved for future use, and they must be zero 🧚
Bits 25-32: Message Type 🦋 The message type tells you what kind of message you're dealing with, and there are a bunch of options:
Type 0: Regular Message 💜 All host-to-host communication happens through regular messages. They come in several sub-types, which live in bits 77-80:
- 0: Standard. The IMP uses its full message and error control facilities, and host blocking (see section 2.4) may occur.
- 1: Standard, short-blocking. See section 2.4.
- 2: Uncontrolled, short-blocking. See section 2.4.
- 3: Uncontrolled. The IMP will perform no message-control functions for this type of message, and network flow and congestion control (see section 2.4) may cause loss of the message. Also see 1822(3.6) and section 2.3.
- 4-15: Unassigned.
Type 1: Error Without Message ID ⚠️ See 1822(3.3).
Type 2: Host Going Down 📉 See 1822(3.3).
Type 3: Name Declaration Message (NDM) 📣 The host uses this message to declare which of its 1822L names is or is not effective (see section 2.2), or to make all of its names non-effective. The first 16 bits of the data portion of the NDM message, after the leader and any padding, hold the number of 1822L name entries in the message. Next come the 1822L name entries, each 32 bits long. The first 16 bits of each one is a 1822L name, and the second 16 bits is either the integer zero or the integer one. Zero means the name should not be effective, and one means the name should be effective. The IMP will reply with an NDM Reply message (see section 3.2) that tells you which names are now effective and which aren't. Here's what an NDM message looks like, leader included (printed in hexadecimal) 👀
1 16 17 32 33 48
+----------------+----------------+----------------+
| | | |
| 0D00 | 0003 | 0000 |
| | | |
+----------------+----------------+----------------+
49 64 65 80 81 96
+----------------+----------------+----------------+
| | | |
| 0000 | 0000 | 0000 |
| | | |
+----------------+----------------+----------------+
97 112 113 128 129 144
+----------------+----------------+----------------+
| | | |
| # of entries | 1822L name #1 | 0 or 1 |
| | | |
+----------------+----------------+----------------+
145 160 161 176
+----------------+----------------+
| | |
| 1822L name #2 | 0 or 1 | etc.
| | |
+----------------+----------------+Figure 6. NDM Message Format
An NDM with zero entries will cause all current effective names for the host to become non-effective 🫶
Type 4: NOP 🧁 This lets the IMP know which style of leader the host wants to use. A 1822L NOP means the host wants 1822L leaders, and an 1822 NOP means the host wants 1822 leaders. All of the other remarks about the NOP message in 1822(3.3) still hold. The host should always send NOPs in groups of three to insure proper reception by the IMP. Also see section 2.5 for more on how the NOP message gets used.
Type 8: Error with Message ID ⚠️ See 1822(3.3).
Types 5-7, 9-255: Unassigned. 🌈
Bits 33-48: Source Host 💫 This field holds one of the source host's 1822L names (or, alternatively, the 1822L address of the host port the message is being sent over). Unlike 1822, the IMP does not fill this in automatically. A host can be known by several names and might want to pick a specific one as the source, and different messages from the same host don't have to use the same name here. Every source name used is checked for authorization, effectiveness, and whether it actually belongs to this host. Messages with names that fail any of these checks won't be delivered, and an error message will get sent back to the source host instead. If the host puts its 1822L Address in this field, that address gets checked to insure it really represents the host port where the message came from. If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST contain the source host's 1822L address (see Figure 4 in section 2.2).
Bits 49-64: Destination Host 🎯 This field holds the 1822L name or address of the destination host. If it's a name, the name gets checked for effectiveness, and if it isn't effective, an error message goes back to the source host. If the message is destined for an 1822 host on a non-C/30 IMP, this field MUST contain the destination host's 1822L address (see Figure 4 in section 2.2).
Bits 65-76: Message ID 🪪 This is a host-specified identification used in all type 0 and type 8 messages, and it's also used in type 2 messages. In type 0 messages, bits 65-72 are also called the Link Field, and they should contain values specified in Assigned Numbers [3] that match the host-to-host protocol being used.
Bits 77-80: Sub-type 🔧 This field works as a modifier for message types 0, 2, 4, and 8.
Bits 81-96: Unused, must be zero. 😌
3.2. IMP-to-Host 1822L Leader Format ✨
Here's the layout for the IMP-to-Host leader:
1 4 5 8 9 16
+--------+--------+----------------+
| | 1822L | |
| Unused | I2H | Handling Type |
| | Flag | |
+--------+--------+----------------+
17 20 21 22 24 25 32
+--------+-+------+----------------+
| |T|Leader| |
| Unused |R|Flags | Message Type |
| |C| | |
+--------+-+------+----------------+
33 48
+----------------------------------+
| |
| Source Host |
| |
+----------------------------------+
49 64
+----------------------------------+
| |
| Destination Host |
| |
+----------------------------------+
65 76 77 80
+-------------------------+--------+
| | |
| Message ID |Sub-type|
| | |
+-------------------------+--------+
81 96
+----------------------------------+
| |
| Message Length |
| |
+----------------------------------+Figure 7. IMP-to-Host 1822L Leader Format
Bits 1-4: Unused and set to zero. 🫧
Bits 5-8: 1822L IMP-to-Host Flag 🏷️ This field is set to decimal 14 (1110 in binary).
Bits 9-16: Handling Type 🎀 This holds the value the source host assigned (see section 3.1). This field is only used in message types 0, 5-9, 11 and 15.
Bits 17-20: Unused and set to zero. 🌷
Bit 21: Trace Bit 🔍 If this bit is equal to one, the source host marked the message for tracing as it moves through the network. See 1822(5.5).
Bits 22-24: Leader Flags 🚩
- Bit 22: Available as a destination host flag.
- Bits 23-24: Reserved for future use, set to zero.
Bits 25-32: Message Type: 💌
okay so this field is basically the vibe check for the whole message 💅 here's the full lineup:
- Type 0: Regular Message ✨ all host-to-host communication happens through these. They come in several sub-types, and the sub-type field (bits 77-80) is the same as the one sent in the host-to-IMP leader (see section 3.1) 🫶
- Type 1: Error in Leader 🙈 see 1822(3.4)
- Type 2: IMP Going Down 💀 see 1822(3.4)
- Type 3: NDM Reply 🌸 this is the reply to the NDM host-to-IMP message (see section 3.1). It has the same number of entries as the NDM message it's answering, and each listed 1822L name comes with a zero or a one. A zero means the name is not effective, and a one means it's now effective 💜
- Type 4: NOP 🧚 the host should discard this message. It's used during initialization of the IMP/host communication. The Destination Host field holds the 1822L Address of the host port the NOP is being sent over, and all other fields are unused
- Type 5: Ready for Next Message (RFNM) 🦋 see 1822(3.4)
- Type 6: Dead Host Status 🥀 see 1822(3.4)
- Type 7: Destination Host or IMP Dead (or unknown) 💀 this one gets sent when a message is for a destination the IMP can't reach. The message to the "dead" destination gets discarded. See 1822(3.4) for the full list of sub-types. If it's answering a standard (type 0, sub-type 0 or 1) message, a Dead Host Status message follows it with more info about the dead host. If it's answering an uncontrolled (type 0, sub-type 2 or 3) message, only sub-type 1 (The destination host is not up) gets used, and no Dead Host Status message follows
- Type 8: Error in Data 😭 see 1822(3.4)
- Type 9: Incomplete Transmission 🍓 the transmission of the named message was incomplete for some reason. It's kinda like an RFNM, but it's a failure indication instead of a success one. This message is also used by the short-blocking feature to say the named message got rejected because it would've made the IMP block the host for a long time. See section 2.4 for more on short-blocking. Its sub-types are:
- 0: The destination host didn't accept the message quickly enough.
- 1: The message was too long.
- 2: The host took more than 15 seconds to transmit the message to the IMP. This time is measured from the last bit of the leader through the last bit of the message.
- 3: The message got lost in the network because of IMP or circuit failures.
- 4: The IMP couldn't accept the entire message within 15 seconds because of unavailable resources. This sub-type is only used in response to non-short-blocking messages. If a short-blocking message timed out, it gets answered with one of the sub-types 6-10.
- 5: A Source IMP I/O failure happened during receipt of this message.
- Sub-types 6-10 are all issued in response to a short-blocking message that timed out (one that would've made the host blocked for a long time). They're designed to give the host a hint about why it timed out and which other messages would also time out. See section 2.4.2 for more details on each of these.
- 6: The message timed out because of connection set-up delay. Further messages to the same host (if on the same connection) may also be affected.
- 7: The message timed out because of end-to-end flow control. Further messages to the same host on the same connection will also be affected.
- 8: A destination IMP buffer shortage caused the message to time out. This affects multi-packet standard messages to the specified host, but shorter messages or messages to hosts on other IMPs may not be affected.
- 9: Network congestion control caused the message to be rejected. Messages to hosts on other IMPs may not be affected, however.
- 10: A local resource shortage kept the IMP from accepting the message within the short-blocking timeout period.
- 11-15: Unassigned.
- Type 10: Interface Reset ✨ see 1822(3.4)
- Type 15: 1822L Name or Address Error 🚨 this gets sent in response to a type 0 message from a host that had an erroneous Source Host or Destination Host field. Its sub-types are:
- 0: The Source Host 1822L name is not authorized or not effective.
- 1: The Source Host 1822L address doesn't match the host port used to send the message.
- 2: The Destination Host 1822L name is not authorized.
- 3: The Destination Host 1822L name is authorized but not effective, even though the named host is up. If the host were actually down, a type 7 message would be returned, not a type 15.
- 4: The Source or Destination Host field contains a 1822L name, but the host being addressed is on a non-C/30 IMP (see Figure 4 in section 2.2).
- 5-15: Unassigned.
- Types 11-14,16-255: Unassigned. 🫥
Bits 33-48: Source Host: 🌷
for type 0 messages, this field holds the 1822L name or address of the host that started the message. All replies to the message should be sent to the host named here. For message types 5-9, 11 and 15, this field holds the source host field that was used in a previous type 0 message sent by this host 🫶
Bits 49-64: Destination Host: 🎀
for type 0 messages, this field holds the 1822L name or address the message was sent to. This lets the destination host figure out how the source host specified it 🧐 For message types 5-9, 11 and 15, this field holds the destination host field that was used in a previous type 0 message sent by this host ✨
Bits 65-76: Message ID: 🍒
for message types 0, 5, 7-9, 11 and 15, this is the value the source host assigned to identify the message (see section 3.1). This field is also used by message types 2 and 6 🦋
Bits 77-80: Sub-type: 🧁
this field works as a modifier for message types 0-2, 4-7, 9, 11 and 15 💅
Bits 81-96: Message Length: 📏
this field only shows up in type 0 and type 3 messages. It's the actual length in bits of the message (not counting the leader, the leader padding, or the hardware padding), as computed by the IMP 💖
4. REFERENCES ✨
[1] Specifications for the Interconnection of a Host and an IMP, BBN Report 1822, May 1978 Revision.
[2] E. C. Rosen et. al., ARPANET Routing Algorithm Improvements, IEN 183 (also published as BBN Report 4473, Vol. 1), August 1980, pp. 55-107.
[3] J. Postel, Assigned Numbers, RFC 790, September 1981, p. 10.
INDEX 🔥
1822...................................................... 4
1822 address.............................................. 6
1822 host................................................. 5
1822L..................................................... 4
1822L address............................................. 7
1822L host................................................ 5
1822L name................................................ 6
authorized................................................ 9
blocking................................................. 16
congestion control................................... 22, 39
connection........................................... 20, 38
destination host..................................... 32, 40
effective................................................ 10
flow control......................................... 20, 38
handing type......................................... 27, 35
incomplete transmission message...................... 19, 37
leader flags......................................... 27, 35
link field............................................... 32
logical addressing........................................ 4
message ID........................................... 32, 41
message length........................................... 41
message type......................................... 28, 35
multi-homing.............................................. 4
NDM.................................................. 10, 28
NDM reply............................................ 10, 36
NOC....................................................... 9
NOP........................................... 5, 22, 30, 36
outstanding.............................................. 21
priority bit............................................. 27
regular message...................................... 28, 35
RFNM..................................................... 36
short-blocking feature................................... 15
short-blocking message............................... 19, 28
source host.......................................... 31, 40
standard message......................................... 28
sub-type............................................. 32, 41
symmetric................................................. 5
trace bit............................................ 27, 35
uncontrolled message................................. 14, 28📦 where this page comes from
- ietf: rfc802 1981-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms