From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc851.txt | 2773 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2773 insertions(+) create mode 100644 doc/rfc/rfc851.txt (limited to 'doc/rfc/rfc851.txt') diff --git a/doc/rfc/rfc851.txt b/doc/rfc/rfc851.txt new file mode 100644 index 0000000..1131f85 --- /dev/null +++ b/doc/rfc/rfc851.txt @@ -0,0 +1,2773 @@ + + + + + Request for Comments: 851 + Obsoletes RFC: 802 + + + + + + + The ARPANET 1822L Host Access Protocol + + + + RFC 851 + + + + + + Andrew G. Malis + ARPANET Mail: malis@bbn-unix + + + + + + Bolt Beranek and Newman Inc. + 50 Moulton St. + Cambridge, MA 02238 + + + + + + April 1983 + + + + + + This RFC specifies the ARPANET 1822L Host Access Protocol, which + is a successor to the existing 1822 Host Access Protocol. 1822L + allows ARPANET hosts to use logical names as well as 1822's + physical port locations to address each other. The RFC is also + being presented as a solicitation of comments on 1822L, + especially from host network software implementers and + maintainers. + + + + + + + + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + Table of Contents + + + + + 1 INTRODUCTION.......................................... 1 + 2 THE ARPANET 1822L HOST ACCESS PROTOCOL................ 4 + 2.1 Addresses and Names................................. 6 + 2.2 Name Translations................................... 8 + 2.2.1 Authorization and Effectiveness................... 8 + 2.2.2 Translation Policies............................. 11 + 2.2.3 Reporting Destination Host Downs................. 13 + 2.2.4 1822L and 1822 Interoperability.................. 16 + 2.3 Uncontrolled Packets............................... 18 + 2.4 Establishing Host-IMP Communications............... 20 + 2.5 Counting RFMS When Using 1822L..................... 22 + 2.6 1822L Name Server.................................. 24 + 3 1822L LEADER FORMATS................................. 27 + 3.1 Host-to-IMP 1822L Leader Format.................... 28 + 3.2 IMP-to-Host 1822L Leader Format.................... 35 + 4 REFERENCES........................................... 43 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - i - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + FIGURES + + + + + 1822 Address Format....................................... 6 + 1822L Name Format......................................... 7 + 1822L Address Format...................................... 7 + Communications between different host types.............. 17 + Host-to-IMP 1822L Leader Format.......................... 28 + NDM Message Format....................................... 31 + IMP-to-Host 1822L Leader Format.......................... 35 + Name Server Reply Format................................. 39 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - ii - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 1 INTRODUCTION + + + This RFC specifies the ARPANET 1822L Host Access Protocol, which + + will allow hosts to use logical addressing (i.e., host names that + + are independent of their physical location on the ARPANET) to + + communicate with each other. This new host access protocol is + + known as the ARPANET 1822L (for Logical) Host Access Protocol, + + and is a successor to the current ARPANET 1822 Host Access + + Protocol, which is described in sections 3.3 and 3.4 of BBN + + Report 1822 [1]. Although the 1822L protocol uses different + + Host-IMP leaders than the 1822 protocol, the IMPs will continue + + to support the 1822 protocol, and hosts using either protocol can + + readily communicate with each other (the IMPs will handle the + + translation automatically). + + + There is one major restriction to the new 1822L protocol: it + + will be implemented in C/30 IMPs only, and will therefore only be + + usable by hosts connected to C/30 IMPs, as Honeywell and Pluribus + + IMPs do not have sufficient memory to hold the new programs and + + tables. This restriction also means that logical addressing + + cannot be used to identify a host on a non-C/30 IMP. While this + + is not a problem on the ARPANET, which only has C/30 IMPs, the + + restriction will apply if logical addressing is used on any + + network that mixes C/30 and non-C/30 IMPs. + + + + + + - 1 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + The RFC's terminology is consistent with that used in Report + + 1822, and any new terms will be defined when they are first used. + + Familiarity with Report 1822 (section 3 in particular) is + + assumed. As could be expected, the RFC makes many references to + + Report 1822. As a result, it uses, as a convenient abbreviation, + + "see 1822(x)" instead of "please refer to Report 1822, section x, + + for further details". + + + This RFC updates, and obsoletes, RFC 802. The changes from that + + RFC include: + + + o The Short Blocking Feature, which had also been described in + + RFC 802, now has its own RFC, RFC 852 [2]. It was moved to its + + own RFC, since it is completely independent of logical + + addressing. + + + o In section 2.2, descriptions of the three address selection + + policies and of host error handling have been added. + + + o In section 2.3, the IMP's uncontrolled packet service has been + + further improved. This applies to hosts using 1822 as well as + + 1822L. + + + o Pointers on using RFNM counting with 1822L have been added as + + section 2.5. + + + + + + + - 2 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + o Section 2.6 describes the new "1822L name server" in the IMP, + + which makes use of two new Host-to-IMP messages to allow hosts + + to do their own name-to-address mapping. + + + o In section 3.2, the subtypes for the type 15 (1822L Name or + + Address Error) IMP-to-Host message have been changed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - 3 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 2 THE ARPANET 1822L HOST ACCESS PROTOCOL + + + The ARPANET 1822L Host Access Protocol allows a host to use + + logical addressing to communicate with other hosts on the + + ARPANET. Basically, logical addressing allows hosts to 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) [3] gives the use of + + logical addressing considerable justification. Among the + + advantages it cites are: + + + o The ability to refer to each host on the network by a name + + independent of its location on the network. + + + o Allowing different hosts to share the same host port on a + + time-division basis. + + + o Allowing a host to use multi-homing (where a single host uses + + more than one port to communicate with the network). + + + o 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 + + + + - 4 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 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. + + + + + + + + + + + + + - 5 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 Format + + + + These 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: + + + + + + + + + + - 6 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + + + + 1 16 + +--------------------------------+ + | | + | 1822L name | + | | + +--------------------------------+ + + Figure 2. 1822L Name Format + + + + The 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 Format + + + + This format allows 1822L hosts to directly address hosts 0-63 at + + IMPs 1-255 (IMP 0 does not exist). Note that the highest host + + + + - 7 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + numbers are reserved for addressing the IMP's internal fake + + hosts. At this writing, the IMP has seven fake hosts, so host + + numbers 57-63 address the IMP fake hosts, while host numbers 0-56 + + address real hosts external to the IMP. As the number of IMP + + fake hosts changes, this boundary point will also change. + + + + + 2.2 Name Translations + + + There are a number of factors that determine how an 1822L name is + + translated by the IMP 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; + + which legal translations shouldn't be attempted because a + + particular host port is down; and the interoperability between + + 1822 and 1822L hosts. These issues are discussed in the + + following sections. + + + + + 2.2.1 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, can have one or + + more 1822L names (logical addresses). Hosts using 1822L can then + + use these names to address the hosts in the network independent + + of their physical locations. Because of the implementation + + + + - 8 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + constraints mentioned in the introduction, hosts on non-C/30 IMPs + + cannot be assigned 1822L names. To circumvent this restriction, + + however, 1822L hosts can also use 1822L addresses to access all + + of the other hosts. + + + 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). 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. + + + + - 9 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 consider, one for 1822L hosts and another for + + 1822 hosts. The following discussion only pertains to hosts on + + C/30 IMPs. + + + When an IMP sees an 1822L host come up on a host port, the IMP + + has no way of knowing which host has just come up (several hosts + + may share the same port, or one host may prefer to be known by + + different names at different times). This requires the host to + + declare itself to the IMP before it can actually send and receive + + messages. This function is performed by a new host-to-IMP + + message, the Name Declaration Message (NDM), which lists the + + names that the host would like to be known by. The IMP checks + + its tables to see if each of the names is authorized, and sends + + an NDM Reply to the host 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 on the + + host is that any names it wishes to use can become effective only + + if they are authorized. + + + In the second case, if a host comes up on a C/30 IMP using the + + 1822 protocol, the IMP automatically makes the first name the IMP + + + + - 10 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + finds in its tables for that host become effective. Thus, even + + though the host is using the 1822 protocol, it can still receive + + messages from 1822L hosts via its 1822L name. Of course, it can + + also receive messages from an 1822L host via its 1822L address as + + well. (Remember, the distinction between 1822L names and + + addresses is that the addresses correspond to physical locations + + on the network, while the names are strictly logical + + identifiers). The IMPs translate between the different leaders + + and send the proper leader in each case (see section 2.2.4). + + + The third question above has by now already been answered. When + + an 1822L host comes up, it uses the NDM message to tell the IMP + + which host it is (which names it is known by). Even if this is a + + shared port, the IMP knows 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. + + + + + 2.2.2 Translation Policies + + + Several hosts can share the same 1822L name. If more than one of + + these hosts is up at the same time, any messages sent to that + + 1822L name will be delivered to just one of the hosts sharing + + that name, and a RFNM will be returned as usual. However, the + + + + - 11 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 1822L + + name in this manner. + + + Similarly, 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 + + 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 1822L address or a specific 1822L + + 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 pre-determined on a per-name + + basis). The three policies are: + + + o Attempt each translation in the order in which the physical + + addresses are listed in the IMP's translation tables, to find + + + + + - 12 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + the first reachable physical host address. This list is + + always searched from the top whenever an uncontrolled packet + + is to be sent or an end-to-end connection has to be created. + + This is the most commonly used policy. + + + o Selection of the closest physical address, which uses the + + IMP's routing tables to find the translation to the + + destination IMP with the least delay path. + + + o Use load leveling. This is similar to the second policy, but + + differs in that searching the address list for a valid + + translation starts at the address following where the previous + + translation search ended. This attempts to spread out the + + load from any one IMP's hosts to the various host ports + + associated with a particular name. Note that this is NOT + + network-wide load leveling, which would require a distributed + + algorithm and tables. + + + + + 2.2.3 Reporting Destination Host Downs + + + As was explained in report 1822, and as will be discussed in + + greater detail in section 2.5, whenever regular messages are sent + + by a host, the IMP opens a subnetwork connection to each + + destination host from the source host. A connection will stay + + open at least as long as there are any outstanding (un-RFNMed) + + + + - 13 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + messages using it and both the source and destination hosts stay + + up. + + + 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 1822 or an 1822L address is being used to specify the + + destination host, then the source host will receive a type 7 + + (Destination Host Dead) message from the IMP. + + A2. If an 1822L name is being used to specify the destination + + host, and the name maps to only one authorized host port, + + then a type 7 message will also be sent to the source host. + + A3. If an 1822L name is being used to specify the destination + + host, and the name maps to more than one authorized host + + port, then the IMP 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 + + (1822L Name or Address Error), subtype 5 (no effective + + translations) message (see section 3.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 + + + + + - 14 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + the name maps to more than one destination port. + + + 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 1822 or an 1822L 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 an 1822L name is being used to specify the destination + + host, then the source host will receive a type 9 (Incomplete + + Transmission), subtype 3 (message lost due to network + + failure) 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). + + + The above two algorithms also apply when a host stays up, but + + declares the destination name for an existing connection to no + + longer be effective. In this case, however, the type 7 messages + + above will be replaced by type 15, subtype 3 (name not effective) + + messages. + + + Section 2.3 discusses how destination host downs are handled for + + uncontrolled packets. + + + + + - 15 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 2.2.4 1822L and 1822 Interoperability + + + As has been previously stated, 1822 and 1822L hosts can + + intercommunicate, and the IMPs will automatically handle any + + necessary leader and address format conversions. However, not + + every combination of 1822 and 1822L hosts allows full + + interoperability with regard to the use of 1822L names. + + + The following figure illustrates how these addressing + + combinations are handled, showing how each type of host can + + access every other type of host. There are three types of hosts: + + "1822 on C/30" signifies an 1822 host that is on a C/30 IMP, + + "1822L" signifies an 1822L host (on a C/30 IMP), and "1822 on + + non-C/30" signifies a host on an non-C/30 IMP (which cannot + + support the 1822L protocol). The table entry shows the protocol + + and host address format(s) that the source host can use to reach + + the destination host. + + + + + + + + + + + + + + + + + + + + - 16 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + + + + 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 an 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 + + + + + + + + + + + + + + - 17 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 2.3 Uncontrolled Packets + + + Uncontrolled packets (see 1822(3.6)) present a unique problem for + + the 1822L protocol. Uncontrolled packets use none of the normal + + ordering and error-control mechanisms in the IMP, and do not use + + the normal subnetwork connection facilities. As a result, + + uncontrolled packets need to carry all of their overhead with + + them, including source and destination names. If 1822L names are + + used when sending an uncontrolled packet, additional information + + is now required by the subnetwork when the packet is transferred + + to the destination IMP. This means that less host-to-host data + + can be contained in the packet than is possible between 1822 + + hosts. + + + Uncontrolled packets that are sent between 1822 hosts may contain + + not more than 991 bits of data. Uncontrolled packets that are + + sent to and/or from 1822L hosts are limited to 32 bits less, or + + not more than 959 bits. Packets that exceed this length will + + result in an error indication to the host, and the packet will + + not be sent. This error indication represents an enhancement to + + the previous level of service provided by the IMP, which would + + simply discard an overly long uncontrolled packet without + + notification. + + + + + + + + - 18 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + Other enhancements that are provided for uncontrolled packet + + service are a notification to the host of any errors that are + + detected by the host's IMP when it receives the packet. A host + + will be notified if an uncontrolled packet contains an error in + + the 1822L name specification, such as if the name is not + + authorized or effective, if the remote host is unreachable (which + + is indicated by none of its names being effective), if network + + congestion control throttled the packet before it left the source + + IMP, or for any other reason the source IMP was not able to send + + the packet on its way. + + + In most cases, the host will not be notified if the uncontrolled + + packet was lost once it was transmitted by the source IMP. + + However, the IMP will attempt to notify the source host if a + + logically-addressed uncontrolled packet was mistakenly sent to a + + host that the source IMP thought was effective, but which turned + + out to be dead or non-effective at the destination IMP. This + + non-delivery notice is sent back to the source IMP as an + + uncontrolled packet from the destination IMP, so the source host + + is not guaranteed to receive this indication. + + + If the source IMP successfully receives the non-delivery notice, + + then the source host will receive a type 15 (1822L Name or + + Address Error), subtype 6 (down or non-effective port) message. + + If the packet is resubmitted or another packet is sent to the + + + + - 19 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + same destination name, and there are no available effective + + translations, then the source host will receive a type 15, + + subtype 5 (no effective translations) message if the destination + + name has more than one mapping; or will receive either a type 7 + + (Destination Host Dead) or a type 15, subtype 3 (name not + + effective) message if the destination name has a single + + translation. + + + Those enhancements to the uncontrolled packet service that are + + not specific to logical addressing will be available to hosts + + using 1822 as well as 1822L. However, logically-addressed + + uncontrolled packets must be used in order to receive any + + indication that the packet was lost once it has left the source + + IMP. + + + + + 2.4 Establishing Host-IMP Communications + + + When a host comes up on an IMP, or after there has been a break + + in the 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 allows the IMP + + and host to recover from most any failure in the other or in + + their communications path, including a break in mid-message. + + + + + + + - 20 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + The first messages that a host should send to its IMP are three + + NOP messages. Three messages are required to insure that at + + least one message will be properly read by the IMP (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 several functions: they + + synchronize the IMP with the host, they tell the IMP how much + + padding the host requires between the message leader and its + + body, and they also 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 will send + + six NOPs, alternating three 1822 NOPs with three 1822L NOPs. + + Thus, the host will see three NOPs no matter which protocol it is + + using. The NOPs will be followed by two Interface Reset + + messages, one of each style. If the IMP receives a NOP from the + + host while the above sequence is occurring, the IMP will only + + send the remainder of the NOPs and the Interface Reset in the + + proper style. The 1822 NOPs will contain the 1822 address of the + + host interface, and the 1822L NOPs will contain the corresponding + + 1822L address. + + + Once the IMP and the host have sent each other the above + + messages, regular communications can commence. See 1822(3.2) for + + + + - 21 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + further details concerning the ready line, host tardiness, and + + other issues. + + + + + 2.5 Counting RFMS When Using 1822L + + + When a host submits a regular message using an 1822 leader, the + + IMP checks for an existing simplex virtual circuit connection + + from the source host to the destination host. If such a + + connection already exists, it is used. Otherwise, a new + + connection from the source host port to the destination host port + + is opened. In either case, there may be at most eight messages + + outstanding on that connection at any one time. If a host + + submits a ninth message on that connection before it receives a + + reply for the first message, then the host will be blocked until + + the reply is sent for the first message. + + + Such connections can stay open for some time, but are timed out + + after three minutes of no activity, or can be closed if there is + + contention for the connection blocks in either the source or + + destination IMP. However, a connection will never be closed as + + long as there are any outstanding messages on it. This allows a + + source host to count the number of replies it has received for + + messages to each destination host address in order to avoid being + + blocked by submitting a ninth outstanding message on any + + + + + - 22 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + connection. + + + When a host submits a regular message using an 1822L leader, a + + similar process occurs, except that in this case, connections are + + distinguished by the source name/destination name combination. + + When the message is received from a host, the IMP first looks for + + an open connection for that same source name/destination name + + pair. If such a connection is found, then it is used, and no + + further name translation is performed. If, however, no open + + connection was found, then the destination name is translated, + + and a connection opened to the physical host port. As long as + + there are any outstanding messages on the connection it will stay + + open, and it will have the same restriction that only eight + + messages may be outstanding at any one time. Thus, a source host + + can still count replies to avoid being blocked, but they must be + + counted on a source name/destination name pair basis, instead of + + just by destination host address as before. + + + Since connections are based on the source name as well as the + + destination name, this implies that there may be more than one + + open connection from physical host port A to physical host port + + B, which would allow more than 8 outstanding messages + + simultaneously from the first to the second port. However, for + + this to occur, either the source or destination names, or both, + + must differ from one connection to the next. For example, if the + + + + - 23 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + names "543" and "677" both translate to physical port 3 on IMP + + 51, then the host on that port could open four connections to + + itself by sending messages from "543" to "543", from "543" to + + "677", from "677" to "543", and from "677" to "677". + + + As has already been stated, the destination names in regular + + messages are only translated when connections are first opened. + + Once a connection is open, that connection, and its destination + + physical host port, will continue to be used until it is closed. + + If, in the meantime, a "better" destination host port belonging + + to the same destination name became available, it would not be + + used until the next time a new connection is opened to that + + destination name. + + + + + 2.6 1822L 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 + + IMP to always deliver messages using a destination name to the + + same host port. + + + + + - 24 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + In these cases, the host can submit a type 11 (Name Server + + Request) message to the IMP, which requests the IMP to translate + + the destination 1822L name and return a list of the addresses to + + which it maps. The IMP 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 from the IMP. See section 3.2 + + for a complete description of the message's contents. + + + Using this information, the source host can make an informed + + decision on which of the physical host ports corresponding to an + + 1822L name to use, and can subsequently send the messages to that + + port, rather than to the name. + + + The IMP also supports a different type of name service. A host + + needs to issue a Name Declaration Message to the IMP in order to + + make its names effective, but it may not wish to keep its names + + in some table or file in the host. In this case, it can ask the + + IMP 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 IMP, and the IMP replies with a type 12 (Port List + + Reply) message. It contains, for the host port over which the + + IMP received the request and sent the reply, the number of names + + + + + - 25 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 3.2 + + contains a complete description of the reply's contents. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - 26 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 3 1822L LEADER FORMATS + + + The following sections describe the formats of the leaders that + + precede 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 the two + + leaders, and all of the existing functionality of the 1822 + + leaders has been retained. 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 been moved to the second byte. + + The third and fourth words contain the Source and Destination + + 1822L Name, respectively. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - 27 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 + + + + + + + - 28 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 desired by the host. 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). + + + Bits 22-24: Leader Flags: + + Bit 22: A flag available for use by the destination host. + + See 1822(3.3) for a description of its use by the IMP's + + TTY Fake Host. + + Bits 23-24: Reserved for future use, must be zero. + + + + + + + - 29 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + Bits 25-32: Message Type: + + Type 0: Regular Message - All host-to-host communication + + occurs via regular messages, which have several sub- + + types, found in bits 77-80. These sub-types are: + + 0: Standard - The IMP uses its full message and error + + control facilities, and host blocking may occur. + + 3: Uncontrolled Packet - The IMP will perform no + + message-control functions for this type of + + message, and network flow and congestion control + + may cause loss of the packet. 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) - This message is + + used by the host to declare which of its 1822L names is + + or is not effective (see section 2.2.1), or to make all + + of its names non-effective. The first 16 bits of the + + data portion of the NDM message, following the leader + + and any leader padding, contains the number of 1822L + + names contained in the message. This is followed by + + the 1822L name entries, each 32 bits long, of which the + + first 16 bits is a 1822L name and the second 16 bits + + contains either of the integers zero or one. Zero + + + + - 30 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + indicates that the name should not be effective, and + + one indicates that the name should be effective. The + + IMP will reply with a NDM Reply message (see section + + 3.2) indicating which of the names are now effective + + and which are not. Pictorially, a NDM message has the + + following format (including the leader, which is + + 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 + + + + + + + + - 31 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + An NDM with zero entries will cause all current + + effective names for the host to become non-effective. + + Type 4: NOP - This allows the IMP to know which style of + + leader the host wishes to use. A 1822L NOP signifies + + that the host wishes to use 1822L leaders, and an 1822 + + NOP signifies that the host wishes to use 1822 leaders. + + All of the other remarks concerning the NOP message in + + 1822(3.3) still hold. The host should always issue + + NOPs in groups of three to insure proper reception by + + the IMP. Also see section 2.4 for a further discussion + + on the use of the NOP message. + + Type 8: Error with Message ID - see 1822(3.3). + + Type 11: Name Server Request - This allows the host to use + + the IMP's logical addressing tables as a name server. + + The destination name in the 1822L leader is translated, + + and the IMP replies with a Name Server Reply message, + + which lists the physical host addresses to which the + + destination name maps. + + Type 12: Port List Request - This allows the physical host + + to request the list of names that map to the host port + + over which this request was received by the IMP. The + + IMP replies with a Port List Reply message, which lists + + the names that map to the port. + + Types 5-7,9-10,13-255: Unassigned. + + + + - 32 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + Bits 33-48: Source Host: + + This field contains one of the source host's 1822L names + + (or, alternatively, the 1822L address of the host port the + + message is being sent over). This field is not + + automatically filled in by the IMP, as in the 1822 protocol, + + because the host may be known by several names and may wish + + to use a particular name as the source of this message. All + + messages from the same host need not use the same name in + + this field. Each source name, when used, is checked for + + authorization, effectiveness, and actually belonging to this + + host. Messages using names that do not satisfy all of these + + requirements will not be delivered, and will instead result + + in an error message being sent back into the source host. + + If the host places its 1822L address in this field, the + + address is checked to insure that it actually represents the + + host port where the message originated. 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.4). + + + Bits 49-64: Destination Host: + + This field contains the 1822L name or address of the + + destination host. If it contains a name, the name will be + + checked for effectiveness, with an error message returned to + + + + + - 33 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + the source host if the name is not effective. 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.4). + + + Bits 65-76: Message ID: + + This is a host-specified identification used in all type 0 + + and type 8 messages, and is also used in type 2 messages. + + When used in type 0 messages, bits 65-72 are also known as + + the Link Field, and should contain values specified in + + Assigned Numbers [4] appropriate for the host-to-host + + protocol being used. + + + Bits 77-80: Sub-type: + + This field is used as a modifier by message types 0, 2, 4, + + and 8. + + + Bits 81-96: Unused, must be zero. + + + + + + + + + + + + + + + + + + + - 34 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 3.2 IMP-to-Host 1822L Leader Format + + + + + + 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 + + + + + + + - 35 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 has the value assigned by the source host (see section + + 3.1). This field is only used in message types 0, 5-9, and + + 15. + + + Bits 17-20: Unused and set to zero. + + + Bit 21: Trace Bit: + + If equal to one, the source host designated this message for + + tracing as it proceeds 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: + + Type 0: Regular Message - All host-to-host communication + + occurs via regular messages, which have several sub- + + types. The sub-type field (bits 77-80) is the same as + + 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). + + + + - 36 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + Type 3: NDM Reply - This is a reply to the NDM host-to-IMP + + message (see section 3.1). It will have the same + + number of entries as the NDM message that is being + + replying to, and each listed 1822L name will be + + accompanied by a zero or a one (see figure 6). A zero + + signifies that the name is not effective, and a one + + means that the name is now effective. + + Type 4: NOP - The host should discard this message. It is + + used during initialization of the IMP/host + + communication. The Destination Host field will contain + + the 1822L Address of the host port over which the NOP + + is being sent. 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) - See + + 1822(3.4). + + Type 8: Error in Data - See 1822(3.4). + + Type 9: Incomplete Transmission - See 1822(3.4). + + Type 10: Interface Reset - See 1822(3.4). + + Type 11: Name Server Reply - This reply to the Name Server + + Request host-to-IMP message contains a word with the + + selection policy and the number of physical addresses + + to which the destination name maps, followed by two + + words per physical address: the first word contains an + + + + - 37 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 1822L address, and the second word contains a bit + + signifying whether or not that particular translation + + is effective and the routing distance (in 6.4 ms units) + + to the address's IMP. In figure 8, EFF is 1 for + + effective and 0 for non-effective, and POL is a two-bit + + number indicating the selection policy for the name + + (see section 2.2.2): + + 0: First reachable. + + 1: Closest physical address. + + 2: Load leveling. + + 3: Unused. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - 38 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + + + + 1 16 17 32 33 48 + +----------------+----------------+----------------+ + | | | | + | 0E00 | 000B | 0000 | + | | | | + +----------------+----------------+----------------+ + 49 64 65 80 81 96 + +----------------+----------------+----------------+ + | | | | + | dest. name | 0000 | 0000 | + | | | | + +----------------+----------------+----------------+ + 97 112 113 128 129 144 + +-+--------------+----------------+-+--------------+ + |P| | |E| | + |O| # of addrs | 1822L addr #1 |F| routing dist | + |L| | |F| | + +-+--------------+----------------+-+--------------+ + 145 160 161 176 + +----------------+-+--------------+ + | |E| | + | 1822L addr #2 |F| routine dist | etc. + | |F| | + +----------------+-+--------------+ + + Figure 8. Name Server Reply Format + + + + Type 12: Port List Reply - This is the reply to the Port + + List Request host-to-IMP message. It contains the + + number of names that map to this physical host port, + + followed by two words per name: the first word contains + + an 1822L name that maps to this port, and the second + + contains either a zero or a one, signifying whether or + + not that particular translation is effective. The + + format is identical to the type 3 NDM Reply message + + + + - 39 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + (see figure 6). + + Type 15: 1822L Name or Address Error - This message is sent + + in response to a type 0 message from a host that + + contained 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 does not match the + + host port used to send the message. + + 2: The Destination Host 1822L name is not authorized. + + 3: The physical host to which this singly-homed + + Destination Host name translated is authorized and + + up, but not effective. If the host was 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.4). + + 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 is resubmitted, there may be another effective + + host port to which the IMP may be able to attempt + + + + - 40 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + to send the packet. + + 7: Logical addressing is not in use in this network. + + 8-15: Unassigned. + + Types 13-14,16-255: Unassigned. + + + Bits 33-48: Source Host: + + For type 0 messages, this field contains the 1822L name or + + address of the host that originated the message. All + + replies to the message should be sent to the host specified + + herein. For message types 5-9 and 15, this field contains + + the source host field used in a previous type 0 message sent + + by this host. + + + Bits 49-64: Destination Host: + + For type 0 messages, this field contains the 1822L name or + + address that the message was sent to. This allows the + + destination host to detect how it was specified by the + + source host. For message types 5-9 and 15, this field + + contains the destination host field used in a previous type + + 0 message sent by this 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 3.1). This field is also used by message types 2 + + + + + - 41 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 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 contained in type 0, 3, 11, and 12 messages + + only, and is the actual length in bits of the message + + (exclusive of leader, leader padding, and hardware padding) + + as computed by the IMP. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + - 42 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + 4 REFERENCES + + + [1] Specifications for the Interconnection of a Host and an IMP, + + BBN Report 1822, December 1981 Revision. + + + [2] A. Malis, The ARPANET Short Blocking Feature, Request For + + Comments 852, April 1983. + + + [3] 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. + + + [4] J. Postel, Assigned Numbers, Request For Comments 820, + + January 1983, p. 11. + + + + + + + + + + + + + + + + + + + + + + + + + + + + - 43 - + + + + 1822L Host Access Protocol April 1983 + RFC 851 + + + + INDEX + + + + + 1822...................................................... 4 + 1822 address.............................................. 6 + 1822 host................................................. 5 + 1822L..................................................... 4 + 1822L address............................................. 7 + 1822L host................................................ 5 + 1822L name................................................ 6 + address selection policy................................. 12 + authorized................................................ 9 + blocking................................................. 22 + closest physical address................................. 13 + connection............................................... 22 + destination host..................................... 33, 41 + effective................................................ 10 + first reachable.......................................... 12 + handing type......................................... 29, 36 + host downs............................................... 13 + leader flags......................................... 29, 36 + link field............................................... 34 + load leveling............................................ 13 + logical addressing........................................ 4 + message ID........................................... 34, 41 + message length........................................... 42 + message type......................................... 30, 36 + multi-homing.............................................. 4 + name server...................................... 24, 32, 37 + NDM.................................................. 10, 30 + NDM reply............................................ 10, 37 + NOC....................................................... 9 + NOP........................................... 5, 20, 32, 37 + priority bit............................................. 29 + regular message...................................... 30, 36 + RFNM................................................. 22, 37 + source host.......................................... 33, 41 + standard message......................................... 30 + sub-type............................................. 34, 42 + symmetric................................................. 5 + trace bit............................................ 29, 36 + uncontrolled packet.................................. 18, 30 + + + + + + + - 44 - + + -- cgit v1.2.3