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/rfc1005.txt | 1907 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1907 insertions(+) create mode 100644 doc/rfc/rfc1005.txt (limited to 'doc/rfc/rfc1005.txt') diff --git a/doc/rfc/rfc1005.txt b/doc/rfc/rfc1005.txt new file mode 100644 index 0000000..65722cd --- /dev/null +++ b/doc/rfc/rfc1005.txt @@ -0,0 +1,1907 @@ + + + + + + +Network Working Group Atul Khanna, Andy Malis +Request for Comments: 1005 BBN Communications Corp. + May 1987 + + + The ARPANET AHIP-E Host Access Protocol (Enhanced AHIP) + + +1. Status of this Memo + + This RFC is a proposed specification for the encoding of Class A + IP addresses for use on ARPANET-style networks such as the Milnet + and Arpanet, and for enhancements to the ARPANET AHIP Host Access + Protocol (AHIP; formerly known as 1822). These enhancements + increase the size of the PSN field, allow ARPANET hosts to use + logical names to address each other, allow for the communication + of type-of-service information from the host to the PSN and + enable the PSN to provide congestion feedback to the host on a + connection basis. Distribution of this memo is unlimited. + Comments on this RFC should be sent to the netmail address + "ahipe@bbn.com". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khanna & Malis [Page 1] + +RFC 1005 May 1987 + + + 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 + + + + + + + + + + + + +Khanna & Malis [Page 2] + +RFC 1005 May 1987 + + + 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............................ 30 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khanna & Malis [Page 3] + +RFC 1005 May 1987 + + +1 INTRODUCTION + +This RFC is a proposed specification for the encoding of Class A +IP addresses for use on ARPANET-style networks such as the Milnet +and Arpanet, and for enhancements to the AHIP Protocol (AHIP is the +preferred term for what has previously been known as the 1822 +protocol). These enhancements and modifications are partially +motivated by a need to overcome the current address limitation +of 256 PSNs per network and by a desire to allow hosts to take +advantage of logical addressing with minimal change to their AHIP +software. This enhanced AHIP protocol will be referred to as +"AHIP-E". These enhancements will: + + + 1. Increase the size of the PSN field to 10 bits. + + 2. Allow hosts to use logical names (i.e., host names that are + independent of physical location on the network) in addition to + physical port addresses to communicate with each other. + + 3. Enable the host to specify a type-of-service to the PSN. + + 4. Provide a mechanism for the PSN to communicate subnetwork + congestion information to the host on a destination host basis. + This will give the host an opportunity to selectively reduce + its congesting flows, thus preventing all of its flows from + being blocked b y the network. Currently, a host has no way of + knowing which of its flows is experiencing congestion; + consequently, it is possible that one congesting flow can + result in the blocking of all the host's flows . + + 5. 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 +capabilities without making substantial changes to its AHIP +implementation. In particular, the specification provides three +versions of AHIP-E: version 0 is current AHIP with no changes; version 1 +allows use of logical and extended addressing with minimal change to +code; version 2 constitutes full-fledged AHIP-E. This is described in +further detail in chapter 6. + +This RFC's terminology is consistent with that used in BBN Report 1822 +[1], and any new terms are 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". + + + +Khanna & Malis [Page 4] + +RFC 1005 May 1987 + + +The rest of this RFC is organized as follows. Chapter 2 describes the +new mapping between IP class A addresses and subnetwork hosts. Chapter +3 discusses logical addressing. Chapter 4 describes the enhancements +related to type-of-service and reliability specification and to +congestion and precedence feedback. Chapter 5 includes a specification +of the new message types and their formats. Finally, chapter 6 +describes the AHIP-E version numbering scheme. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khanna & Malis [Page 5] + +RFC 1005 May 1987 + + +2 IP ISSUES + +This section discusses the changes to the mapping between Class A IP +addresses [5] and subnet addresses. These changes are made necessary +by: + + 1. The introduction of logical names. + + 2. 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 in length, with 8 bits devoted to +network number and 24 to the local address. In particular, they are of +the form n.h.l.i, where n,h,l and i are decimal integers less than 256. +AHIP addresses are 24 bits in length. The current ARPANET-style class A +mapping is as follows (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.1 + + + +The LH (logical host) field is used by the hosts only and is not passed +to the network. + + + + + +Khanna & Malis [Page 6] + +RFC 1005 May 1987 + + +2.2 Requirements and Constraints Affecting New Class A Mapping + +This section discusses some of the requirements and constraints that +were considered significant in determining the new address mapping. + + 1. Address Mapping Stability Requirement: + + Any current IP physical address with l (logical host) = 0 + should remain unchanged under the new design. For example, + the binary string corresponding to 10.0.0.51 should continue + to refer to sri-nic.arpa (assuming, of course, that sri-nic + continues to reside on psn 51, port 0). This requirement is + motivated by a desire to avoid a network-wide address + switchover. + + 2. Existing implementation compatibility: + + Existing compliant implementations of AHIP should continue to + function for destinations with addresses fitting the + restrictions in 1. In other words, such addresses should + continue to refer to their original destinations, not only + with the AHIP-E implementation (which is the condition in 1), + but also with current ones. + + 3. 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 specified by the DDN + X.25 Specification [6]. In particular, 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. + + 4. Maximum number of PSNs that can be supported: + + The new design should support a maximum of more than 256 PSNs + per network. + + + + + + + + + + +Khanna & Malis [Page 7] + +RFC 1005 May 1987 + + +2.3 New Interpretation of IP Address Fields + +The following is 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.2 + + +The fields have the following meanings: + + 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 + + + + + + + + +Khanna & Malis [Page 8] + +RFC 1005 May 1987 + + +AHIP-E physical addresses and logical names have the following formats: + + 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.3 + +The reserved address format is currently undefined and will be rejected +by the PSN, which will return an error message (message type 6, subtype +3) to the host. + + ----------------------------------------------------------------- + |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. | + ----------------------------------------------------------------- + + + + + + + + +Khanna & Malis [Page 9] + +RFC 1005 May 1987 + + +2.4 Discussion of the New Mapping + +This section presents an evaluation of the design in terms of the +requirements in section 2.2 + + 1. 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. + + + 2. 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. + + 3. 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 + host h on PSN i. If h >= 64, the address is considered + logical, i.e., it refers to the host whose logical name is h + concatenated with i. + + 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. + + + + + + +Khanna & Malis [Page 10] + +RFC 1005 May 1987 + + + 4. 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. + +There are other possibilities for errors, caused by incorrect address +translation between IP and current AHIP: + + 1. 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. + + 2. 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. Recal 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. + + + + + + + + + + + + + +Khanna & Malis [Page 11] + +RFC 1005 May 1987 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khanna & Malis [Page 12] + +RFC 1005 May 1987 + + +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: + +o 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). + +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. + +o 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.1 + + + + + +Khanna & Malis [Page 13] + +RFC 1005 May 1987 + + +AHIP-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.2 + +Logical 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.3 + +3.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. + + + + + + + + + + + +Khanna & Malis [Page 14] + +RFC 1005 May 1987 + + +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 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. + +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 + + + +Khanna & Malis [Page 15] + +RFC 1005 May 1987 + + +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). Thus, 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: + +o 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. + + + + +Khanna & Malis [Page 16] + +RFC 1005 May 1987 + + +o 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. + +o 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 + + + +Khanna & Malis [Page 17] + +RFC 1005 May 1987 + + + 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 + + + +Khanna & Malis [Page 18] + +RFC 1005 May 1987 + + +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. + + + + + + +Khanna & Malis [Page 19] + +RFC 1005 May 1987 + + +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 reliability + + +The 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)). +Messages from host A to host B using the same destination name and of +the same handling type and type-of- service will use the same +connection, while those that differ in either type-of-service, +destination name or handling type will use separate connections. In +other words, for a given source host and destination name pair, a new +connection will be established whenever a message with a new handling- +type/type-of- service combination is received. + + + + + + + + +Khanna & Malis [Page 20] + +RFC 1005 May 1987 + + +4.2 Subnet Congestion Feedback + +This section describes the new messages that are part of the mechanism +used by the PSN to communicate subnetwork congestion information to the +host. Note that a host will be blocked by the PSN when its share of +buffers in the PSN is used up. Thus, this information, which is +communicated on a connection basis, will give the host an opportunity to +selectively reduce its congesting flows, thus preventing all of its +flows from getting blocked. Currently, a host has no way of knowing +which of its flows is experiencing congestion; consequently, it is +possible that one congesting flow can result in the blocking of all the +host's flows. + +Three new PSN-to-host messages have been created. These messages are: + + 1. STOP: Blocking Imminent -- Stop Sending on this + Connection (Message type 13) + + 2. 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. + + 3. 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 correspond to 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 new messages have been created: + + 1. Network Not Accepting Messages at this Precedence Level + (Message type 9, subtype 7). + + 2. Network Precedence Level Cutoff Change (Message type + 17). + +The first message will be generated whenever the host attempts to send a +message at a precedence level lower than the cutoff. The cutoff +represents a precedence level below which no traffic may be submitted + + + +Khanna & Malis [Page 21] + +RFC 1005 May 1987 + + +into the subnetwork; note that a cutoff set to the lowest possible +precedence level implies that 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 will be 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khanna & Malis [Page 22] + +RFC 1005 May 1987 + + +5 FORMATS FOR NEW AHIP-E MESSAGES + +The following sections describe the formats of the leaders that precede +messages between an AHIP-E host and its PSN. The formats are almost +identical to those of AHIP (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.1 + + +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 delay + 1 -- low delay + Bit 10: Throughput Bit: + 0 -- normal throughput + 1 -- high throughput + Bit 11: Reliability Bit: + + + +Khanna & Malis [Page 23] + +RFC 1005 May 1987 + + + 0 -- normal reliability + 1 -- high reliability + +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. + +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 PSN uses its full message and error + control facilities, and host blocking may occur. + 3: Uncontrolled Packet - The PSN 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). 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 message is | + used by the host to declare which of its logical names | + is or is not effective (see section 3.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 | + logical names contained in the message. This is | + followed by the logical name entries, each 32 bits | + + + +Khanna & Malis [Page 24] + +RFC 1005 May 1987 + + + long, of which the first 16 bits is a logical name and | + the second 16 bits contains either of the integers | + zero or one. Zero indicates that the name should not | + be effective, and one indicates that the name should be | + effective. Note that only the names explicitly in the | + NDM will remain enabled after the NDM is processed | + (assuming that they are authorized). The PSN will | + reply with a NDM Reply message (see section 5.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, and without any 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.2 + + + + + + + + + +Khanna & Malis [Page 25] + +RFC 1005 May 1987 + + + An NDM with zero entries will cause 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 | + are used to determine the host's AHIP-E version -- see | + chapter 6. | + + Type 8: Error with Message ID - see 1822(3.3). + + Type 11: Name Server Request - This allows the host to use | + the PSN's logical addressing tables as a name server. | + The destination name in the AHIP-E leader is | + translated, and the PSN replies with a Name Server | + Reply message, which lists the physical host addresses | + to which the destination name maps. The type-of- | + service bits (bits 9-11) should be set correctly by | + the host, as the Name Server Reply message contains | + information about characteristics of the subnetwork | + route(s) to that destination, which will depend on the | + type-of-service. | + + 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 PSN. The | + PSN replies with a Port List Reply message, which | + lists the names that map to the port. | + + Types 5-7,9-10,13-255: Unassigned. + + Bits 33-40: Handling Type: + The top two bits (33 and 34) specify the precedence of the + connection. There are 4 precedence levels, level 3 being + the highest and level 0 the lowest. Bits 35-40 are used to + specify up to 64 separate connections at a particular + precedence level and type-of-service. + + Bits 41-64: Destination Host: + This field contains the name or address of the destination + host, as described in figures 3.3 and 3.2 respectively. If + it contains a name, the name will be checked for + effectiveness, with an error message returned to the source + host if the name is not effective. + + 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 + + + +Khanna & Malis [Page 26] + +RFC 1005 May 1987 + + + Assigned Numbers [3] 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 + + +5.2 PSN-to-Host AHIP-E Leader Format + + + 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.3 + +Bits 1-4: Unused and set to zero. + +Bits 5-8: Format Flag + This field is set to decimal 15 (1111 in binary). + +Bits 9-11: Type-of-Service + Specified by the source host (see section 5.1). + +Bits 12-20: Unused, must be set to zero. + +Bit 21: Trace Bit: + + + +Khanna & Malis [Page 27] + +RFC 1005 May 1987 + + + If equal to one, the source host has 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 + that 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 a reply to the NDM host-to-PSN | + message (see section 5.1). It has the same number of | + entries as the NDM message to which it replies, and | + each listed name is accompanied by a zero or a one | + (see figure 5.2). 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 PSN/host + communication. The Destination Host field will + contain the physical 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 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). In + addition to its already defined sub-types, this + message has two new sub-types: + 6: Logically Addressed Host Went Down - A logically | + + + +Khanna & Malis [Page 28] + +RFC 1005 May 1987 + + + addressed message was lost in the network because | + the destination host to which it was being | + delivered went down. The message should be | + resubmitted by the source host, since there may | + be another effective host port to which the | + message could be delivered (see section 2.2.3). | + 7: Network Not Accepting Messages at this Precedence | + Level - bits 33 and 34 encode the minimum | + precedence level currently being accepted by the | + network. See section 4.3. + + Type 10: Interface Reset - See 1822(3.4). + + Type 11: Name Server Reply - This reply to the Name Server | + Request host-to-PSN message contains, following the | + leader and any leader padding, a word with the | + selection policy and the number of physical addresses | + to which the destination name maps, followed by five | + octets per physical address: the first three octets | + contain an AHIP-E address, and the last two contain a | + bit signifying whether or not that particular | + translation is effective and the routing distance | + (expected network transmission delay, in 6.4 ms units) | + to the address's PSN for the type-of-service specified | + in the Name Server Request being replied to. This | + type-of-service will be included in the Name Server | + Reply leader. In figure 5.4, which includes the | + leader without any leader padding and has 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, and POL is a two-bit number indicating | + the selection policy for the name (see section 3.2.2): | + + 0: First reachable. + 1: Closest physical address. | + 2: Load leveling. | + 3: Unused. + + + + + + + + + + + + + + +Khanna & Malis [Page 29] + +RFC 1005 May 1987 + + + 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 | + contains a logical 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(see figure 5.2). | + + Type 13: STOP -- Stop Sending on this Connection. See | + + + +Khanna & Malis [Page 30] + +RFC 1005 May 1987 + + + 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 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. | + 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 PSN may be able | + to attempt to send the packet. | + 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 currently | + being accepted by the network. 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)). This field is 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 which are responses to messages from the + + + +Khanna & Malis [Page 31] + +RFC 1005 May 1987 + + + 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 contained in type 0 messages only, and is the + actual length in bits of the message (exclusive of leader, + leader padding, and hardware padding) as computed by the + PSN. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khanna & Malis [Page 32] + +RFC 1005 May 1987 + + +6 AHIP-E VERSIONS + +This specification provides three versions of AHIP-E and allows a host +to specify its version in bits 13-16 of the leader of the NOP. The PSN +will set the version of a host based on the value contained in the most +recent NOP that it has received from the host. Thus, a host can change +the PSN's idea of its version by issuing a NOP containing a different +version value. Note that the version field in all other host-to-PSN +messages will be ignored by the PSN. + +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, thus, is nothing but current AHIP. + +A version 0 host will not receive any of the new AHIP-E messages from +the PSN, nor will the PSN expect any of the new host-to-PSN message +types from the host. The type-of-service bits will always be set to +zero in the PSN-to-host leader. + +Version 1: + +A version 1 host will be able to use logical names to address other +hosts, will be able to use the 10-bit PSN field, will be able to specify +desired type-of-service to the PSN, but will not receive any of the new +AHIP-E messages from the PSN. The PSN will not expect any of the new +host-to-PSN message types from the host either. + +To implement version 1, a host need only make the following changes to +its AHIP implementation: + + 1. Set the version number field to 1 when sending type 4 + messages (NOPs). + + 2. When sending type 0 messages, copy IP address bits 8-31 + into bits 41-64 of the AHIP leader. + + 3. 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. In addition to being able to take +advantage of the features described under version 1 above, it should be +able to send and receive all the new AHIP-E messages described in this +document. + + + +Khanna & Malis [Page 33] + +RFC 1005 May 1987 + + +7 REFERENCES + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Khanna & Malis [Page 34] + \ No newline at end of file -- cgit v1.2.3