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
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.
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.
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.