RFC 1005
ARPANET AHIP-E Host Access Protocol (enhanced AHIP)
RFC 1005 💖 The ARPANET AHIP-E Host Access Protocol (Enhanced AHIP)
- Network Working Group 🌸
- Authors: Atul Khanna and Andy Malis, BBN Communications Corp. 👩💻👨💻
- Request for Comments: 1005
- Date: May 1987 📅
- Status: a proposed specification (see Section 1 below) 📜
- Obsoletes / Updates: nothing is listed in this document's header 🤷♀️
Table of Contents 📚
1 INTRODUCTION.......................................... 4
2 IP ISSUES............................................. 6
2.1 Current Interpretation of Class A IP Address
Fields
................................................... 6
2.2 Requirements and Constraints Affecting New
Class A Mapping
................................................... 7
2.3 New Interpretation of IP Address Fields............. 8
2.4 Discussion of the New Mapping.......................10
2.5 Interoperability between Current AHIP and
AHIP-E
...................................................11
3 LOGICAL ADDRESSING................................... 13
3.1 Addresses and Names................................ 13
3.2 Name Translations.................................. 14
3.2.1 Authorization and Effectiveness.................. 15
3.2.2 Translation Policies............................. 16
3.2.3 Reporting Destination Host Downs................. 17
3.3 Establishing Host-PSN Communications............... 18
3.4 Name Server........................................ 19
4 OTHER CHANGES........................................ 20
4.1 Type-of-Service Specification...................... 20
4.2 Subnet Congestion Feedback......................... 21
4.3 Precedence Level Information....................... 21
5 FORMATS FOR NEW AHIP-E MESSAGES...................... 23
5.1 Host-to-PSN AHIP-E Leader Format................... 23
5.2 PSN-to-Host AHIP-E Leader Format................... 27
6 AHIP-E VERSIONS...................................... 33
7 REFERENCES........................................... 34
FIGURES
2.1 IP Class A Mapping................................... 6
2.2 New Class A IP Address Interpretation................ 8
2.3 AHIP-E Address and Name.............................. 9
3.1 Current AHIP Address Format......................... 13
3.2 AHIP-E Address Format............................... 14
3.3 Logical Name Format................................. 14
5.1 Host-to-PSN AHIP-E Leader Format.................... 23
5.2 NDM Message Format.................................. 25
5.3 PSN-to-Host AHIP-E Leader Format.................... 27
5.4 Name Server Reply Format............................ 301. Status of this Memo ✨
okay bestie, so this one is a proposed specification 📜 for how Class A IP addresses get encoded on ARPANET-style networks like Milnet and Arpanet 🌐. It also brings upgrades to the ARPANET AHIP Host Access Protocol (AHIP, which used to be called 1822) 🦋.
The upgrades are giving main character energy 👑. The PSN field gets bigger 📈. Hosts can use logical names to find each other 🧚. Hosts can tell the PSN what type-of-service they want 🎀. And the PSN can send congestion feedback to the host on a connection basis 🌸. Distribution of this memo is unlimited, so share it with everyone 🥰.
Comments on this RFC should be sent to the netmail address "ahipe@bbn.com" 💌.
1 INTRODUCTION 🦋
so this RFC is again a proposed spec for encoding Class A IP addresses on ARPANET-style networks like Milnet and Arpanet 🌐. It also covers enhancements to the AHIP Protocol, where AHIP is the preferred term for what used to be called the 1822 protocol 💅. Part of the reason for all this is that the current limit is 256 PSNs per network 🚧, and bestie, nobody wants to hit a wall like that. The other part is that hosts should be able to use logical addressing with minimal change to their AHIP software 🫶. This enhanced protocol is called "AHIP-E" ✨. AHIP-E will:
- Increase the size of the PSN field to 10 bits. 📏
- Allow hosts to use logical names (host names that don't depend on where something physically sits on the network) as well as physical port addresses to talk to each other 🧚.
- Enable the host to specify a type-of-service to the PSN 🎀.
- Provide a mechanism for the PSN to tell the host about subnetwork congestion on a destination host basis 🚦. This gives the host a chance to selectively slow down its congesting flows, so the network doesn't block all of its flows 😭. Right now a host has no way of knowing which of its flows is congesting, so one congesting flow can end up blocking all of the host's flows 💀.
- Enable the PSN to inform the host about changes in precedence cutoff levels and about precedence level violations 📣.
A host can take advantage of the extended and logical addressing without making big changes to its AHIP implementation 🙌. There are three versions of AHIP-E. Version 0 is current AHIP with no changes 🐣. Version 1 allows extended and logical addressing with minimal change to code 🌈. Version 2 is full-fledged AHIP-E 👑. You can read more about this in chapter 6 🦋.
This RFC's terminology matches BBN Report 1822 [1], and any new terms get defined the first time they show up 📖. Familiarity with Report 1822 (section 3 in particular) is assumed 🧐. The RFC references Report 1822 a LOT, so it uses the shorthand see 1822(x) instead of writing out "please refer to Report 1822, section x, for further details" 🙈.
The rest of this RFC is organized like this. Chapter 2 describes the new mapping between IP class A addresses and subnetwork hosts 🗺️. Chapter 3 discusses logical addressing 🏷️. Chapter 4 covers the enhancements for type-of-service and reliability specification, plus congestion and precedence feedback 🔁. Chapter 5 includes the spec for the new message types and their formats 📦. Finally, chapter 6 describes the AHIP-E version numbering scheme 🔢.
2. IP ISSUES 🧩
This section talks about the changes to the mapping between Class A IP addresses [5] and subnet addresses 🗺️. These changes are needed because of two things:
- The introduction of logical names 🏷️.
- The expansion of the PSN-number field 📈.
Note that this RFC does not affect Class B and C mappings [5] 🙅♀️.
2.1. Current Interpretation of Class A IP Address Fields 🔍
Class A IP addresses are 32 bits long 🧮. They have 8 bits for the network number and 24 bits for the local address. Specifically, they look like n.h.l.i, where n, h, l and i are decimal integers less than 256 💕. AHIP addresses are 24 bits long 💫. Here's the current ARPANET-style class A mapping, from RFC 796 🎀:
0 7 8 15 16 23 24 31
+--------+--------+-------+---------+
| net # | HOST | LH | PSN | IP Address
+--------+--------+-------+---------+
8 8 8 8
8 8 8
+--------+--------+--------+
| HOST | ZERO | PSN | AHIP Physical Address
+--------+--------+--------+
41 48 49 56 57 64
(bit positions in the AHIP leader)
IP Class A Mapping
Figure 2.1The LH (logical host) field is only used by the hosts 🙈 and it is not passed to the network 🚫.
2.2. Requirements and Constraints Affecting New Class A Mapping 📋
This section covers some of the requirements and constraints that mattered most when the new address mapping was being figured out 🧠.
- Address Mapping Stability Requirement: Any current IP physical address with
l(logical host) =0should remain unchanged under the new design 🔒. For example, the binary string for10.0.0.51should keep referring tosri-nic.arpa(assuming, of course, thatsri-nicstill lives on psn51, port0) 🖥️. This requirement exists because nobody wants a network-wide address switchover 😵💫. - Existing implementation compatibility: Existing compliant AHIP implementations should keep working for destinations whose addresses fit the restrictions in 1. In other words, those addresses should keep pointing to their original destinations, not just with the AHIP-E implementation (which is the condition in 1), but also with current ones 🫶.
- Compatibility between X.25's IP address to subnet host mapping and AHIP's IP address to subnet host mapping: The AHIP-E IP to host mapping should be able to co-exist, in some sense, with the IP to host mapping in the DDN X.25 Specification [6] 🤝. Specifically, restricted use of the revised IP to DDN host mapping should produce addresses that are consistent with the current X.25 mapping ✨. In other words, there should be a set that includes "sufficiently many" logical names and physical addresses, with the property that each address/name in the set maps onto the same host under both the AHIP and X.25 mappings 💖.
- Maximum number of PSNs that can be supported: The new design should support a maximum of more than 256 PSNs per network 📈🚀.
2.3. New Interpretation of IP Address Fields 🪄
Here's the new interpretation of the IP address field, in the context of ARPANET-style networks 🌐:
Proposed IP Address Interpretation
8 8 1 5 10
+--------+--------+-+-----+----------+
| net # | HOST |0|XXXXX| PSN | Physical Address
+--------+--------+-+-----+----------+
0 7 8 15 17 21 22 31
8 8 2 6 8
+--------+--------+--+------+--------+
| net # | UPPER |11|XXXXXX| LOWER | Logical Name
+--------+--------+--+------+--------+
0 7 8 15 18 23 24 31
16 2 14
+-----------------+--+---------------+
| |10| | Reserved Format
+-----------------+--+---------------+
0 15 18 31
(X = don't care)
New Class A IP Address Interpretation
Figure 2.2The fields mean the following 🌸:
- HOST = host-number 🖥️
- PSN = 10 bit PSN-number field 📏
- UPPER = upper 8 bits of the 16-bit logical name ⬆️
- LOWER = lower 8 bits of the 16-bit logical name ⬇️
AHIP-E physical addresses and logical names look like this, bestie 💖
8 1 5 10
+--------+-+-----+----------+
| HOST |0|XXXXX| PSN | Physical Address
+--------+-+-----+----------+
41 48 55 64
(bit positions in the AHIP leader)
(X = don't care)
8 2 6 8
+--------+--+------+--------+
| UPPER |11|XXXXXX| LOWER | Logical Name
+--------+--+------+--------+
41 48 57 64
(bit positions in the AHIP leader)
+--------+--+---------------+
| |10| | Reserved Address Format
+--------+--+---------------+
41 48 51 64
(bit positions in the AHIP leader)
AHIP-E Address and Name
Figure 2.3The reserved address format is currently undefined, so the PSN will reject it and send back an error message (message type 6, subtype 3) to the host 🙅♀️
Okay, this box is giving main character energy 🎀
-----------------------------------------------------------------
|This design does not require the AHIP-E host to do any processing|
|of the address -- the host need only copy bits 8-31 of the IP |
|address into bits 41-64 of the AHIP leader. The host no longer |
|needs to zero out bits 49-56 of the AHIP leader. The PSN will |
|take care of the AHIP to subnet address conversion. In other |
|words, bits 8-31 of the IP address field should be passed |
|unchanged to the PSN, which interprets them exactly as shown in |
|figure 2.3. |
-----------------------------------------------------------------2.4 Discussion of the New Mapping 💅
Time to judge the design against the requirements from section 2.2 ✨ This section presents an evaluation of the design in terms of the requirements in section 2.2.
- Address mapping stability requirement: Current physical IP addresses will not have to be changed, as long as they have been following the convention of setting
LH= 0. This ensures that bit 16 is set to 0, indicating that the address is physical, and that the PSN number comes out right 🌸 - Existing implementation compatibility: The design meets this requirement, as the address that gets to the PSN has its second octet = 0, which results in its correct interpretation as a physical address 🫶
- Compatibility with the current X.25 IP address to DDN host mapping: The current X.25 IP to HOST mapping [6] is as follows: If
h< 64, the address is considered physical, i.e., it refers to hosthon PSNi. Ifh>= 64, the address is considered logical, i.e., it refers to the host whose logical name ishconcatenated withi.
The design is compatible in a limited sense with the current X.25 logical addressing implementation, as long as logical names are assigned such that host-number > 63 (also PSN-number < 256 which is automatic, given the 16-bit size of the logical name field) and physical addresses are in the range host-number < 64 and PSN-number < 256, with the appropriate setting of bits 16 and 17 of the IP address field. This works because the X.25 mapping ignores the value of the l field, i.e., the third IP address octet 🧚
Given the desire to be able to address more than 64 hosts physically and for PSN numbers > 255, this address assignment restriction should not be considered permanent, but rather as an interim compromise until the hosts' X.25 implementations are revised to incorporate the new mapping between IP and DDN addresses.
- Maximum number of PSNs that can be supported: The design allows addressing of up to 1024 PSNs per network.
2.5 Interoperability between Current AHIP and AHIP-E
This section discusses the interoperability between hosts using current AHIP and AHIP-E. It also discusses the general issue of current AHIP host operation in the AHIP-E addressing environment 👀
The proposed modifications to AHIP have been designed with backward compatibility in mind. However, note that bits 41-64 of the PSN-to-host leader (see 1822(3.4)) will always contain the physical address of the source host. This means that an error could occur when a host on a PSN numbered greater than 255 attempts to send a message to a host running a current AHIP implementation, which interprets the address of the source host as one with PSN-number < 256. Yikes 😭
There are other possibilities for errors, caused by incorrect address translation between IP and current AHIP:
- A host running current AHIP cannot physically address any host on a PSN numbered greater than 255 (see Figure 3.1). Consequently, an error will result if the host attempts to use an address from the NIC host table that has
PSN-number> 255. - If a host running current AHIP attempts to use a logical name that it might have in its host table, an error will occur. This is because the logical name flag bits 16 and 17 of the IP address, bits 49 and 50 of the AHIP leader. Recall that bits 49 - 56 of the AHIP leader get set to zero with current AHIP (see figure 2.1).
Since these errors cannot be detected by the subnetwork, it is essential that all hosts implement at least version 1 AHIP-E (see chapter 6) before PSN numbers over 255 and logical names are assigned. Don't skip this part, periodt ✨
Another aspect of interoperability has to do with the IP LH field, which is currently used by a handful of Arpanet hosts to demultiplex a single host port. The 5 don't-care bits of the physical IP address (bits 17-21) and the 6 don't-care bits of the IP logical name (bits 18-23) can be used for this purpose -- in particular, the use of these bits is divided between the network and external devices, based on administrative agreement. At the very least, the IP addresses of such hosts will have to change to reflect the changed position of the LH field. However, the preferred way to demultiplex a single host port is via the mechanism of logical names. The only change this involves is to get the port expander implementation to look at the entire IP address, rather than just the LH field 🦋
3 LOGICAL ADDRESSING ✨
The modifications to AHIP allow a host to use logical addressing to communicate with other hosts on the network. Basically, logical addressing allows hosts to refer to each other using a logical name (see section 3.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 in the network (especially important if the host has to move to another physical port).
- 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).
- Allowing several hosts that provide the same service to share the same name.
- Allowing a host to provide services that have their own unique names.
3.1 Addresses and Names
The AHIP-E protocol allows two forms of host specification. The first is a slightly modified version of the form used by the current AHIP protocol, the physical address. The second form is the logical name (the terms "name", "logical name" and "logical address" are used interchangeably in this document) 🍓
Current AHIP addresses are the 24-bit host addresses found in AHIP leaders. They have the following format:
8 8 8
+-------------+--------+------------+
| host-number |00000000| PSN-number |
+-------------+--------+------------+
41 48 49 56 57 64
(bit positions in the AHIP leader)
Current AHIP Address Format
Figure 3.1AHIP-E addresses have the following format:
8 1 5 10
+--------+-+-----+----------+
| HOST |0|XXXXX| PSN | Physical Address
+--------+-+-----+----------+
41 48 55 64
(bit positions in the AHIP leader)
(X = don't care)
AHIP-E Address Format
Figure 3.2Logical names are 16-bit unsigned numbers that serve as a logical identifier for one or more hosts. A logical name is the concatenation of two separate octets in the AHIP leader, bits 41-48 (Upper 8) and 57-64 (Lower 8) in particular 🌈
8 2 6 8
+--------+--+------+--------+
| UPPER |11|XXXXXX| LOWER |
+--------+--+------+--------+
41 48 57 64
(bit positions in the AHIP leader)
(X = don't care)
Logical Name Format
Figure 3.33.2 Name Translations
There are a number of factors that determine how a logical name is translated by the PSN into a physical address on the network. These factors include which translations are legal; in what order different translations for the same name should be attempted; and which legal translations should not be attempted because a particular host port is down. These issues are discussed in the following sections 🔥
3.2.1 Authorization and Effectiveness
Every host on a PSN, regardless of whether it is using the AHIP or AHIP-E protocol to access the network, can have one or more logical names. Hosts using AHIP-E can then use these names to address the hosts in the network independent of their physical locations 💜
At this point, several questions arise: How are these names assigned, how do they become known to the PSNs (so that translations to physical addresses can be made), and how do the PSNs 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 PSNs by the Monitoring Center (MC). 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. Physical addresses, which actually refer to physical host ports, are always authorized in this sense 🦋
When the PSN detects that a host has come up on one of its ports, it makes effective the default name(s), if any, for that host. This default action is specified in the configuration table for that host, and can be one of the following: Enable All Names, Enable No Names, Enable One Particular Name. In the case of an AHIP-E host, the default name might not be the one that the host desires to be known as (recall that several hosts may share the same port, or one host may prefer to be known by different names at different times). This requires that an AHIP-E host be able to declare its name to the PSN. This function is
performed by a new host-to-PSN message, the Name Declaration Message (NDM), which lists the names that the host would like to be known by 💖 The PSN checks its tables to see if each name is authorized, then sends an NDM Reply saying which names were actually authorized and can now be used for sending and receiving messages (i.e., which names are effective) ✨ A host can also use an NDM message to change its list of effective names (it can add to and delete from the list) at any time 🔄 The only constraint is that any names a host wishes to use can become effective only if they are authorized 🔐
If a host is using the current AHIP protocol, it can still receive messages from hosts via its logical name 📬 Of course, it can also receive messages from a current AHIP host via its physical address as well. (Remember, the distinction between logical names and physical addresses is that the addresses correspond to physical locations on the network, while the names are strictly logical identifiers 🗺️)
The third question above has by now already been answered 🙌 An AHIP-E host can use the NDM message to tell the PSN which host it is (which names it is known by). So even if this is a shared port, the PSN knows which host is currently connected 👀
WHENEVER A HOST GOES DOWN, ITS NAMES AUTOMATICALLY BECOME NON-EFFECTIVE. 😭 When it comes back up, the default action (from the host's configuration) is taken. If the host wishes to be known by a name other than the default, it will have to issue a NDM. It will also have to do this upon receipt of reset NOPS from the PSN 🫶
3.2.2. Translation Policies ✨
Several hosts can share the same logical name 👯 If more than one of these hosts is up at the same time, any messages sent to that logical name will be delivered to just one of the hosts sharing that name, and a RFNM will be returned as usual. However, the sending host will not receive any indication of which host received the message, and subsequent messages to that name are not guaranteed to be sent to the same host 🎲 Typically, hosts providing exactly the same service could share the same logical name in this manner 💅
Similarly, when a host is multi-homed, the same logical 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 will be used for all messages addressed to the host. However, if the host were up on more than one port, the message would be delivered over just one of those ports, and the subnet would choose which port to use. This port selection could change from message to message 🦋 If a host wanted to insure that certain messages were delivered to it on specific ports, these messages could use either the port's physical address or a specific logical name that referred to that port alone 🎀
Three different address selection policies are available for the name mapping process. When translated, each name uses one of the three policies (the policy is administratively pre-determined on a per-name basis) 📋 The three policies are:
- Attempt each translation in the order in which the physical addresses are listed in the PSN's translation tables, to find the first reachable physical host address. This list is always searched from the top whenever a new virtual circuit connection has to be created. This is the most commonly used policy 👑
- Selection of the closest physical address, which uses the PSN's internal routing tables to find the translation to the destination PSN with the least cost path for the particular type-of-service whenever a new virtual circuit connection has to be created 🛣️
- Use load leveling. This is similar to the first policy, but differs in that searching the address list for a valid translation starts at the address following where the previous translation search ended whenever a new virtual circuit connection has to be created. This attempts to spread out the load from any one PSN's hosts to the various host ports associated with a particular name. Note that this is NOT network-wide load leveling, which would require knowledge about flows throughout the network 🧠
3.2.3. Reporting Destination Host Downs ✨
As is explained in Report 1822, whenever regular messages are sent by a host, the PSN opens a virtual circuit connection to each destination host from the source host 🔗 A new connection is opened for each new source-address/destination-name (or address, as the case might be)/handling-type/type-of-service combination. A connection will stay open at least as long as there are any outstanding (un-RFNMed) messages using it and both the source and destination hosts stay up. Connections are also closed after a period of inactivity 💤
However, the destination host may go down for some reason during the lifetime of a connection 😬 If the host goes down while there are no outstanding messages to it in the network, then the connection is closed and no other action is taken until the source host submits the next message for that destination. At that time, ONE of the following events will occur:
- A1. If a physical address is being used to specify the destination host, then the source host will receive a type 7, subtype 0 (Destination Host Dead) message from the PSN 💀
- A2. If a logical name is being used to specify the destination host, and the name maps to only one authorized host port, then a type 7, subtype 0 message will be sent to the source host 📨
- A3. If a logical name is being used to specify the destination host, and the name maps to more than one authorized host port, then the PSN attempts to open a connection to another authorized and effective host port for that name. If no such connection can be made, the host will receive a type 15 (AHIP Name or Address Error), subtype 5 (no effective translations) message (see section 5.2). Note that a type 7 message cannot be returned to the source host, since type 7 messages refer to a particular destination host port, and the name maps to more than one destination port. However, in the case of a version 0 or 1 host, a type 7, subtype 0 message will be returned for each outstanding message. See chapter 6 for further details on version numbers 🔢
Things get a bit more complicated if there are any outstanding messages on the connection when the destination host goes down 🌀 The connection will be closed, and one of the following will occur:
- B1. If a physical address is being used to specify the destination host, then the source host will receive a type 7 message for each outstanding message 📦
- B2. If a logical name is being used to specify the destination host, then the source host will receive a type 9 (Incomplete Transmission), subtype 6 (message lost due to logically addressed host going down) message for each outstanding message. The next time the source host submits another message for that same destination name, the previous algorithm will be used (either step A2 or step A3). However, in the case of a version 0 or 1 host, a type 7, subtype 0 message will be returned for each outstanding message. See chapter 6 for further details on version numbers 🧾
3.3. Establishing Host-PSN Communications ✨
When a host comes up on a PSN, or after there has been a break in the communications between the host and its PSN (see 1822 (3.2)), the orderly flow of messages between the host and the PSN needs to be properly (re-)established 🤝 This allows the PSN and host to recover from almost any failure in the other or in their communications path, including a break in mid-message 🛠️
The first messages that a host should send to its PSN are three NOPs 🔁 Three messages are required to ensure that at least one message will be properly read by the PSN (the first NOP could be concatenated to a previous message if communications had been broken in mid-stream, and the third provides redundancy for the second). These NOPs serve to synchronize the PSN with the host, to inform the PSN about how much padding the host requires between the message leader and its body, and to specify the host's AHIP-E version number to the PSN (see chapter 6) 🧩
Similarly, the PSN will send three NOPs to the host when it detects that the host has come up 📡 The NOPs will be followed by an Interface Reset message. These NOPs will contain the physical address of the host interface.
Once the PSN and the host have sent each other the above messages, regular communications can commence 🚀 See 1822(3.2) for further details concerning the ready line, host tardiness, and other issues.
3.4. Name Server ✨
There may be times when a host wants to perform its own translations, or might need the full list of physical addresses to which a particular name maps 🔍 For example, a connection-based host-to-host protocol may require that the same physical host port on a multi-homed host be used for all messages using that host-to-host connection, and the host does not wish to trust the PSN to always deliver messages using a destination name to the same host port 🙅♀️
In these cases, the host can submit a type 11 (Name Server Request) message to the PSN, which requests the PSN to translate the destination name and return a list of the addresses to which it maps. The PSN will respond with a type 11 (Name Server Reply) message, which contains the selection policy in use for that name, the number of addresses to which the name maps, the addresses themselves, and for each address, whether it is effective and its routing distance (for the particular type-of-service specified in the Name Server Request message) from the PSN. See section 5.2 for a complete description of these messages' contents 📖
Using this information, the source host could make an informed decision on which of the physical host ports corresponding to a logical name to use, and then send the messages to that port, rather than to the name 🎯
The PSN also supports a different type of name service 💁♀️ A host needs to issue a Name Declaration Message to the PSN in order to change its effective names, but it may not wish to keep its names in some table or file in the host. In this case, it can ask the PSN to tell it which names it is authorized to use 🗝️
In this case, the host submits a type 12 (Port List Request) message to the PSN, and the PSN replies with a type 12 (Port List Reply) message. It contains, for the host port over which the PSN received the request and sent the reply, the number of names that map to the port, the list of names, and whether or not each name is effective. The host can then use this information in order to issue the Name Declaration Message. Section 5.2 contains a complete description of the reply's contents 🎁
4. OTHER CHANGES ✨
This section describes the enhancements to the AHIP protocol involving type-of-service specification, subnet congestion feedback and network precedence level feedback 🔥 Note that only version 2 hosts will receive the congestion and precedence messages described in this section.
4.1. Type-of-Service Specification 💜
Bits 9 and 10 of the AHIP leader, currently unused, will be used by the host to specify desired delay and throughput characteristics to the PSN. Bit 11, also currently unused, will be used to specify reliability. The bits have the following meaning:
Bit 9: delay bit
0 -- normal delay
1 -- low delay
Bit 10: throughput bit
0 -- normal throughput
1 -- high throughput
Bit 11: reliability bit
0 -- normal reliability
1 -- high reliabilityThe values of these bits are consistent with those of IP, and bits 11, 12 and 13 of the IP header can be copied directly into bits 9, 10 and 11 of the AHIP leader 🦋 The type-of-service bits should be considered as extensions of the
"Handling Type" field (bits 33-40 of the AHIP leader, see 1822 (3.3)) is the key to who shares a connection 🔑. Messages from host A to host B with the same destination name, handling type, and type-of-service all ride the same connection 🤝. If any of those three differ, they get their own separate connections 🦋. So for a given source host and destination name pair, a brand-new connection gets set up whenever a message with a new handling-type/type-of-service combo shows up 💖.
4.2. Subnet Congestion Feedback 🚦
This section is all about the new messages the PSN uses to tell the host about subnetwork congestion 🚨. Here's the tea: a host gets blocked by the PSN when its share of buffers in the PSN runs out 😭. This info is sent on a connection basis, so the host gets a chance to selectively ease up on its congesting flows and avoid getting every flow blocked 🙈. Right now a host has no way of knowing which of its flows is congesting, so one bad flow can end up blocking all of the host's flows 💀. Not it 🙅.
Three new PSN-to-host messages have been created. They are:
- STOP: Blocking Imminent -- Stop Sending on this Connection (Message type 13) 🛑
- SLOW: Subnet Congestion -- Send at Slow Rate on this Connection (Message type 14) -- Maintain Window Size of 1, i.e., do not send a new message to this destination host with this type-of-service and handling type until all previous messages have been acknowledged by RFNMs 🐢
- GO: Congestion Subsided -- Send at Regular Rate on this Connection (Message type 16) -- Maintain Window Size of 8 🏎️
These messages may be sent in any order, and they describe states, not transitions 🌀. A participating host should support three states with effective windows of 8, 1 and 0 ✨. The format of these messages can be found in section 5.2 🎀.
4.3. Precedence Level Information 👑
Two brand-new messages just dropped:
- Network Not Accepting Messages at this Precedence Level (Message type 9, subtype 7) 🚫
- Network Precedence Level Cutoff Change (Message type 17) 📣
The first message is generated whenever the host tries to send a message at a precedence level lower than the cutoff 🙅♀️. The cutoff is the precedence level below which no traffic may be submitted into the subnetwork 🚧. Note that a cutoff set to the lowest possible precedence level means no precedence restrictions are in effect 🌈. If the host has chosen not to receive the new AHIP-E messages, then the PSN will send a type 7, sub-type 3 message (communication with the destination host is administratively prohibited) instead 🙃. The second message is generated whenever the network precedence level cutoff changes 🔔. Both messages contain the network precedence cutoff value 💜. The format of these messages can be found in section 5.2 🧚.
5. FORMATS FOR NEW AHIP-E MESSAGES 🧚
Okay, this is the formats section, and it's giving precise. These sections describe the formats of the leaders that come before messages between an AHIP-E host and its PSN 📦. They're almost identical to AHIP's formats (see 1822(3.3) and 1822(3.4)) 👯. New message types are marked by margin bars (as shown | here) 🖍️.
5.1. Host-to-PSN AHIP-E Leader Format 💜
1 4 5 8 13 16 17 20 21 22 24 25 32
+---------+--------+-+-+-+-+------+--------+-+------+----------------+
| | FORMAT |D|T|R|U| | |T|LEADER| |
| UNUSED | FLAG |E|H|E|N| VERS | UNUSED |R|FLAGS | MESSAGE TYPE |
| | (15) |L|R|L|U| | |C| | |
+---------+--------+-+-+-+-+------+--------+-+------+----------------+
33 40 41 64
+----------------------+----------------------------------------------+
| | |
| HANDLING TYPE | DESTINATION HOST |
| | |
+----------------------+----------------------------------------------+
65 76 77 80 81 96
+-------------------------+--------+----------------------------------+
| | | |
| MESSAGE ID |SUB-TYPE| UNUSED |
| | | |
+-------------------------+--------+----------------------------------+
Host-to-PSN AHIP-E Leader Format
Figure 5.1Here's the bit-by-bit breakdown, bestie 🫶:
- Bits 1-4: Unused, must be set to zero. 🫥
- Bits 5-8: Format Flag
- This field is set to decimal 15 (1111 in binary). 🔢
- Bits 9-11: Type-of-Service ⚡
- Bit 9: Delay Bit:
0 -- normal delay1 -- low delay
- Bit 10: Throughput Bit:
0 -- normal throughput1 -- high throughput
- Bit 11: Reliability Bit:
0 -- normal reliability1 -- high reliability
- Bit 9: Delay Bit:
- Bit 12: Unused, must be set to zero. 🫥
- Bits 13-16: AHIP-E Version number
- Ignored by the PSN except in the case of a NOP -- see chapter 6. 🙈
- Bits 17-20: Unused, must be set to 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). 🔍
- Bits 22-24: Leader Flags: 🏳️
- Bit 22: A flag available for use by the destination host. See AHIP(3.3) for a description of its use by the PSN's TTY Fake Host. 🎀
- Bits 23-24: Reserved for future use, must be zero. ✨
5. Leader Stuff (the Message Type era) 💅
Bits 25-32: Message Type: okay bestie, this is where the PSN figures out what kind of message it's dealing with. 🎀
- Type 0: Regular Message 💌 All host-to-host communication happens through regular messages. They come in sub-types, which live in bits 77-80:
- 0: Standard ✨ The PSN uses its full message and error control facilities, and host blocking may occur.
- 3: Uncontrolled Packet 🦋 The PSN does no message-control functions for this one. Network flow and congestion control may drop the packet, so see 1822(3.6) for the deets.
- 1-2,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) 🧚♀️ This is the host's way of announcing which of its logical names are effective (see section 3.2.1), or of making all of its names non-effective. The first 16 bits of the NDM data portion, after the leader and any leader padding, hold the number of logical names in the message. After that come the logical name entries, each 32 bits long. The first 16 bits of an entry are the logical name, and the second 16 bits are either zero or one. Zero means "this name should not be effective," and one means "this name should be effective." 🌸 Only the names explicitly listed in the NDM stay enabled after it's processed (assuming they're authorized). The PSN then sends back an NDM Reply message (see section 5.2) that says which names are effective now and which aren't. Here's the picture, with the leader in hexadecimal and no leader padding:
1 16 17 32 33 48
+----------------+----------------+----------------+
| | | |
| 0F00 | 0003 | 0000 |
| | | |
+----------------+----------------+----------------+
49 64 65 80 81 96
+----------------+----------------+----------------+
| | | |
| 0000 | 0000 | 0000 |
| | | |
+----------------+----------------+----------------+
97 112 113 128 129 144
+----------------+----------------+----------------+
| | | |
| # of entries | name #1 | 0 or 1 |
| | | |
+----------------+----------------+----------------+
145 160 161 176
+----------------+----------------+
| | |
| name #2 | 0 or 1 | etc.
| | |
+----------------+----------------+
NDM Message Format
Figure 5.2An NDM with zero entries causes all current effective names for the host to become non-effective. 🫠
- Type 4: NOP 🌈 See 1822(3.3). Bits 13-16 of the NOP leader determine the host's AHIP-E version. See chapter 6 for that.
- Type 8: Error with Message ID 🔥 See 1822(3.3).
- Type 11: Name Server Request 🔎 This lets the host use the PSN's logical addressing tables as a name server. The destination name in the AHIP-E leader gets translated, and the PSN replies with a Name Server Reply message listing the physical host addresses that the destination name maps to. The type-of-service bits (bits 9-11) should be set correctly by the host, because the Name Server Reply message includes info about the characteristics of the subnetwork route(s) to that destination, which depends on the type-of-service. 👑
- Type 12: Port List Request 🍓 This lets the physical host ask for the list of names that map to the host port this request came in on. The PSN replies with a Port List Reply message that lists the names mapped to that port.
- Types 5-7,9-10,13-255: Unassigned. 🫥
Bits 33-40: Handling Type: 💖 The top two bits (33 and 34) set the precedence of the connection. There are 4 precedence levels: level 3 is the highest and level 0 is the lowest. Bits 35-40 let you specify up to 64 separate connections at a given precedence level and type-of-service. Main character energy. ✨
Bits 41-64: Destination Host: 🎯 This field holds the name or address of the destination host, as described in figures 3.3 and 3.2 respectively. If it's a name, the name gets checked for effectiveness, and if it's not effective, an error message goes back to the source host.
Bits 65-76: Message ID: 🪪 This is a host-specified identifier 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] for the host-to-host protocol being used. 🧃
Bits 77-80: Sub-type: 🎭 This field is a modifier used by message types 0, 2, 4, and 8.
Bits 81-96: Unused 🫧
5.2. PSN-to-Host AHIP-E Leader Format ✨
Here's the PSN-to-host leader layout, bestie. Hold onto your hats:
1 4 5 8 12 16 17 20 21 22 24 25 32
+--------+--------+-+-+-+--------+--------+-+------+----------------+
| | FORMAT |D|T|R| | |T|LEADER| |
| UNUSED | FLAG |E|H|E| UNUSED | UNUSED |R|FLAGS | MESSAGE TYPE |
| | (15) |L|R|L| | |C| | |
+--------+--------+-+-+-+--------+--------+-+------+----------------+
33 40 41 64
+----------------------+----------------------------------------------+
| | |
| HANDLING TYPE | SOURCE HOST |
| | |
+----------------------+----------------------------------------------+
65 76 77 80 81 96
+-------------------------+--------+----------------------------------+
| | | |
| MESSAGE ID |SUB-TYPE| MESSAGE LENGTH |
| | | |
+-------------------------+--------+----------------------------------+
PSN-to-Host AHIP-E Leader Format
Figure 5.3Bits 1-4: Unused and set to zero. 🫧 Zeros all the way down, no drama.
Bits 5-8: Format Flag 🔢 This field is set to decimal 15 (1111 in binary). It's giving consistency. 💅
Bits 9-11: Type-of-Service 🛣️ Specified by the source host (see section 5.1).
Bits 12-20: Unused, must be set to zero. 🌙 Leave it empty, bestie.
Bit 21: Trace Bit: 🔍 If this bit equals one, the source host has marked this message for tracing as it moves through the network. See 1822(5.5). Ooh, detective mode. 🕵️♀️
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 bestie, this is the field where the PSN figures out what kind of message it's dealing with 👀 🔥
- Type 0: Regular Message 💌 Literally all host-to-host communication happens through regular messages, and those come in several sub-types. The sub-type field (bits 77-80) matches what was sent in the host-to-PSN leader (see section 5.1).
- Type 1: Error in Leader 🙈 See 1822(3.4).
- Type 2: PSN Going Down 📉 See 1822(3.4).
- Type 3: NDM Reply 🎀 This is the reply to the NDM host-to-PSN message (see section 5.1). It has the same number of entries as the NDM message it's replying to, and each listed name comes with a zero or a one (see figure 5.2). A zero means the name is not effective, and a one means the name is now effective.
- Type 4: NOP 🫶 The host should discard this message. It's used during initialization of the PSN/host communication. The Destination Host field contains the physical address of the host port the NOP is being sent over. 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 PSN Dead (or unknown) 😭 See 1822(3.4).
- Type 8: Error in Data 🍓 See 1822(3.4).
- Type 9: Incomplete Transmission 🧚 See 1822(3.4). On top of its already defined sub-types, this message gets two new ones:
- 6: Logically Addressed Host Went Down 🌧️ A logically addressed message was lost in the network because the destination host it was headed to went down. The source host should resubmit it, since there may be another effective host port it could be delivered to (see section 2.2.3).
- 7: Network Not Accepting Messages at this Precedence Level 🚧 Bits 33 and 34 encode the minimum precedence level the network is currently accepting. See section 4.3.
- Type 10: Interface Reset 🔄 See 1822(3.4).
- Type 11: Name Server Reply 🗺️ This is the reply to the Name Server Request host-to-PSN message. After the leader and any leader padding, it carries a word with the selection policy and the number of physical addresses the destination name maps to. Then comes five octets per physical address. The first three octets hold an AHIP-E address, and the last two hold a bit saying whether that translation is effective, plus the routing distance (expected network transmission delay, in 6.4 ms units) to the address's PSN for the type-of-service requested in the Name Server Request being replied to. That type-of-service also shows up in the Name Server Reply leader.
Figure 5.4 shows the leader without any leader padding, with type-of-service set to 000. EFF is 1 for effective and 0 for non-effective. The destination name is in the format of figure 3.3. POL is a two-bit number for the selection policy of the name (see section 3.2.2):
- 0: First reachable.
- 1: Closest physical address.
- 2: Load leveling.
- 3: Unused.
1 16 17 32 33 40
+----------------+----------------+--------+
| | | |
| 0F00 | 000B | 00 |
| | | |
+----------------+----------------+--------+
41 64 65 80
+------------------------+-----------------+
| | |
| Destination name | 0000 |
| | |
+------------------------+-----------------+
81 96 97 112
+----------------+-+--------------+
| |P| |
| 0000 |O| # of addrs |
| |L| |
+----------------+-+--------------+
113 136 137 152
+--------------------------+-+-------------+
| |E| |
| AHIP-E addr #1 |F| routing dist|
| |F| |
+--------------------------+-+-------------+
153 176 177 192
+--------------------------+-+-------------+
| |E| |
| AHIP-E addr #2 |F| routing dist| etc.
| |F| |
+--------------------------+-+-------------+
Name Server Reply Format
Figure 5.4- Type 12: Port List Reply 🌷 This is the reply to the Port List Request host-to-PSN message. It contains the number of names that map to this physical host port, followed by two words per name. The first word holds a logical name that maps to this port. The second holds either a zero or a one, saying whether that translation is effective. The format is identical to the type 3 NDM Reply message(see figure 5.2).
- Type 13: STOP 🛑 Stop Sending on this Connection. See section 4.2.
- Type 14: SLOW 🐢 Maintain window size of 1 on this connection. See section 4.2.
- Type 15: Name or Address Error 🙅 This message is sent in response to a type 0 message from a host that contained an erroneous Destination Host field. Its sub-types are:
- 2: The Destination Host name is not authorized.
- 3: The physical host that this singly-homed Destination Host name translated to is authorized and up, but not effective. If the host was actually down, a type 7 message would be returned, not a type 15.
- 5: The multi-homed Destination Host name is authorized but has no available effective translations.
- 6: A logically-addressed uncontrolled packet was sent to a dead or non-effective host port. However, if it's resubmitted, there may be another effective host port the PSN can try to send the packet to.
- 7: Logical addressing is not in use. The PSN has no table of mappings from logical addresses to physical host ports.
- 0, 1, 4, 8-15: Unassigned
- Type 16: GO 🚀 Maintain window size of 8 on this connection. See section 4.2.
- Type 17: Network Precedence Level Cutoff Change 📣 Bits 33 and 34 encode the minimum precedence level the network is currently accepting. See section 4.3.
- Types 18-255: Unassigned. 🫥
Bits 33-40: Handling Type: this has the value assigned by the source host (see 1822(3.1)). It's only used in message types 0, 5-9, and 13-16. 🎀
Bits 41-64: Source Host: see 1882(3.4). For type 0 messages, this contains the physical address of the source host, in the format detailed in figure 3.2. For type 4 messages, this contains the physical address of the local host. For messages of type 5-9, 11 and 13-16 that are responses to messages from the local host, this contains the destination name as specified in the message from the local host. 🌈
Bits 65-76: Message ID: for message types 0, 5, 7-9, and 15, this is the value assigned by the source host to identify the message (see section 5.1). This field is also used by message types 2 and 6. 🪪
Bits 77-80: Sub-type: this field is used as a modifier by message types 0-2, 5-7, 9, and 15. 🧩
Bits 81-96: Message Length: this field is only in type 0 messages. It's the actual length in bits of the message (not counting leader, leader padding, and hardware padding), as computed by the PSN. 📏
6. AHIP-E VERSIONS ✨
Okay so this spec gives us three versions of AHIP-E, and it lets a host pick its version in bits 13-16 of the NOP's leader. 💖 The PSN sets a host's version based on the value in the most recent NOP it got from that host. So a host can change the PSN's idea of its version just by sending a NOP with a different version value. Also, the version field in all other host-to-PSN messages gets ignored by the PSN. Noted, bestie 📝
Version 0
A host that doesn't change its current AHIP implementation will presumably have the version bits in the AHIP leader set to zero. Version 0 is basically just current AHIP. 🌸
A version 0 host won't receive any of the new AHIP-E messages from the PSN, and the PSN won't expect any of the new host-to-PSN message types from it. The type-of-service bits will always be set to zero in the PSN-to-host leader. 🙈
Version 1
A version 1 host can use logical names to address other hosts, can use the 10-bit PSN field, and can specify its desired type-of-service to the PSN. But it won't receive any of the new AHIP-E messages from the PSN, and the PSN won't expect any of the new host-to-PSN message types from it either. 💅
To implement version 1, a host only needs to make these changes to its AHIP implementation:
- Set the version number field to 1 when sending type 4 messages (NOPs).
- When sending type 0 messages, copy IP address bits 8-31 into bits 41-64 of the AHIP leader.
- When sending type 0 messages, copy IP header bits 11-13 to AHIP leader bits 9-11.
Version 2
A version 2 host is one that is fully compliant with the AHIP-E protocol as described in this document. 👑 On top of everything version 1 can do, it should be able to send and receive all the new AHIP-E messages described in this document. Main character energy, honestly 🦋
7. References ✨
okay bestie, this is the receipts section 🧾💅 every source the spec leans on is listed here, so you can go find the originals if you want the full story 🧚
[1] "Specifications for the Interconnection of a Host and an PSN", BBN Report 1822, as found in "DDN Protocol Handbook", December 1985, vol. 3, section 3.10. 🌸
[2] E. C. Rosen et. al., "ARPANET Routing Algorithm Improvements", Internet Experimenter's Note 183 (also published as BBN Report 4473, Vol. 1), August 1980, pp. 55-107. 🦋
[3] J. Reynolds and J. Postel, "Assigned Numbers", Request For Comments 990, November 1986. 💖
[4] J. Postel, ed., "Internet Protocol -- DARPA Internet Program Protocol Specification", Request for Comments 791, September 1981. ✨
[5] J. Postel, "Address Mappings", Request for Comments 796, September 1981, as found in "DDN Protocol Handbook", vol. 3, section 3.4. 🎀
[6] "Defense Data Network X.25 Host Interface Specification", pp. 497-498, DDN protocol handbook, vol. 1, December 1985. 👑
📦 where this page comes from
- ietf: rfc1005 1987-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms