rfc-907

Host Access Protocol specification

Bolt Beranek and Newman Laboratories
date1984-07 streamLegacy statusINTERNET STANDARD pages75 canonicalhttps://www.rfc-editor.org/rfc/rfc907 doi10.17487/RFC0907
This document specifies the Host Access Protocol (HAP). Although HAP was originally designed as the network-access level protocol for the DARPA/DCA sponsored Wideband Packet Satellite Network, it is intended that it evolve into a standard interface SATNET and TACNET (aka MATNET) as well as the Wideband Network. HAP is an experimental protocol, and will undergo further revision as new capabilities are added and/or different satellite networks are suported. Implementations of HAP should be performed in coordination with satellite network development and operations personnel.

updated by

also

Extracted elements (27)

design-rationale §2

Datagrams incur two satellite hops (~0.6s) because channel time is allocated per message via reservation scheduling. Streams incur only one hop (~0.3s) because a recurring channel allocation is pre-established at stream setup time, eliminating the need for per-message reservation. This trade-off imposes strict message-size and interarrival-time discipline on stream senders.

realtime, qos

design-rationale §5

The A/R mechanism can be disabled on a per-link basis (via Restart Complete) or per-message (message number = 0) to operate in a pure discard mode when A/R overhead is unattractive. The Unnumbered Response message provides critical out-of-band feedback even when A/R is fully disabled.

congestion

interoperability-note §2

Bit transmission order within each 16-bit word differs by link-level protocol: HDLC and ARPANET VDH transmit bit 0 (LSB) first through bit 15 (MSB); ARPANET 1822 local and distant host interfaces transmit in the reverse order (bit 15 first). HAP word ordering (word 0 to word N) is the same for all link types.

interoperability-note §3

The Internet/Local flag (word 3, bit 14) indicates whether the data portion contains a standard DoD Internet (IP) header. Setup messages may include an optional IP header between the datagram header and the setup header; the service host replies in the same format (Internet requests get Internet replies). Internet notification messages are not supported.

ip

normative-requirement §6.1 MUST NOT

A host requesting an increased stream allocation must not transmit at the new parameters without first receiving a Reply Code of 4 (stream changed). A host requesting a reduced allocation should decrease its sending rate immediately without waiting for the reply.

congestion

normative-requirement §5 MUST NOT

A message number of zero in a datagram or stream message disables the A/R mechanism for that specific message. The A/R message number field in an A/R word can never be zero for this reason.

normative-requirement §2 MUST

Any HAP message whose received header checksum does not match the checksum computed on the received header information must be discarded.

security

normative-requirement §6 MUST

Setup messages received with bad checksums must be discarded. The setup checksum covers the three setup header words plus all setup message body words.

security

normative-requirement §6 MUST

The host must respond to a SIMP Reply with a Reply Acknowledgment within 1 second. The host should receive a Reply to a setup request requiring global communication within 2 seconds, and to a request requiring only local SIMP communication within 1 second.

protocol-element §6.2

Any member of a group may delete the group at any time (not only the creator), using the 48-bit key for authentication. A Leave operation is local (removes one host from membership), while Delete expunges all knowledge of the group from every SIMP in the network.

multicast

protocol-element §2

Each host on the satellite network is assigned a permanent 16-bit logical address independent of its physical port on the SIMP. These 16-bit addresses are provided in all Host-to-SIMP and SIMP-to-Host data messages in the destination (word 4) and source (word 5) fields.

protocol-element §6.2

Group addressing supports multi-destination delivery by exploiting the satellite broadcast capability, primarily for conferencing. Group creation returns a 16-bit group address and a 48-bit key; the creating host must distribute both out-of-band to prospective members, who must supply the key in their Join Group Requests for network authentication.

multicast, security

protocol-element §2

HAP defines two data message types: datagram messages (two satellite hop delay, ~0.6s) for bursty traffic, and stream messages (one satellite hop delay, ~0.3s) for volatile traffic such as speech requiring guaranteed bandwidth. Each message type can carry up to approximately 16K bits of user data.

qos, realtime

protocol-element §3

HAP supports four priority classes (0=low through 3=high) encoded in bits 8–9 of datagram word 3. Priority is used by the SIMP to arbitrate contention for satellite channel time; for streams, priority governs preemption of lower-priority streams at setup time.

qos

protocol-element §6.1

Host streams have six properties fixed at creation: slot size (words of message text per slot), interval (1/2/4/8 frames of 21.2 ms each), reliability, reliability length, priority, and maximum messages per slot. The stream interval cannot be changed after creation; all other properties can be modified via Change Stream Parameters Request.

qos, realtime

protocol-element §6

Setup layer exchanges use a 3-way handshake: (1) host sends Request to service host (logical address 0), (2) service host returns Reply, (3) host returns Reply Acknowledgment. SIMP-initiated notifications use a 2-way exchange. Each request and notification is assigned a unique ID to allow multiple outstanding operations.

protocol-element §5

The acceptance/refusal (A/R) mechanism uses 8-bit message numbers (modulo 256) in each direction; up to 127 messages may be outstanding at any time. Explicit acceptance or refusal of message number N implicitly applies to all outstanding lower-numbered messages, enabling cumulative acknowledgment.

congestion

protocol-element §3

The GOPRI field (bits 12–13 of word 0) carries advisory information in SIMP-to-Host messages indicating the lowest priority currently being accepted by the SIMP. Hosts may optionally provide similar priority information to the SIMP to avoid originating messages that will be refused.

congestion, qos

protocol-element §9

The Loopback Request control message (Section 9) allows a host or SIMP to detect looped messages by comparing the loopback bit (word 0 bit 14): 0 means sent by host, 1 means sent by SIMP. If an arriving message has the loopback bit equal to the receiver's outgoing value, the message has been looped.

protocol-element §5

The Unnumbered Response control message (type 5) provides critical feedback even when operating in pure discard mode (A/R disabled). It carries a response code (e.g., destination unreachable, protocol violation, illegal stream ID) and response information words identifying the offending address or message.

protocol-element §3

Three forward-error-correction reliability levels (0=low, 1=medium, 2=high) are available to the host via bits 6–7 of datagram word 3. The Reliability Length field (bits 0–5) allows the host to transmit a leading portion of user data (e.g., IP and TCP headers) at maximum reliability while the remainder uses the specified level.

security

security-consideration §6.2

Group membership operations (Join and Delete) are authenticated using a 48-bit key returned at group creation time. This key must be supplied by any host wishing to join or delete the group, minimizing the probability that unwanted hosts will deliberately or inadvertently become members. The key distribution mechanism is outside the scope of HAP.

security, multicast

state-machine §8

Section 8 defines a HAP link restart state diagram governing initialization between host and SIMP. The host sends a Restart Request (with a Reason field indicating the cause), and the SIMP responds with a Restart Complete message that includes a bit enabling or disabling the A/R mechanism for the link. States include uninitialized, restart-pending, and operational.

wire-format §2

Every HAP message consists of an integral number of 16-bit words. Word 0 identifies the message type (bit 15: 0=data, 1=control), word 1 is a header checksum covering all header words, and subsequent words depend on message type. Fields are described by notation WORD#[BIT#] where bits are numbered 0 (LSB) to 15 (MSB).

wire-format §5

The A/R word is 16 bits: bit 15 = 0 (acceptance) or 1 (refusal); bits 8–14 = refusal code (17 codes defined, including priority not accepted, SIMP congestion, destination dead, nonexistent stream ID, message too long); bits 0–7 = A/R message number (never zero, since zero disables A/R for that message).

congestion

wire-format §3

The datagram message header occupies words 0–5: word 0 contains message class, loopback bit, GOPRI, force-channel flag, and 8-bit message number; word 1 is header checksum (negation of 2's-complement sum of words 0–5); word 2 is piggybacked A/R; word 3 carries data type, Internet/Local flag, discard flag, TTL, priority, reliability, and reliability length; words 4–5 carry 16-bit destination and source host addresses. Words 6–N hold up to 16,384 bits (1024 words) of user data.

wire-format §4

The stream message header reuses the same word 0–2 layout as datagrams but word 3 bit 15 is set to 1 (stream type), and bits 0–9 carry the 10-bit Host Stream ID (assigned at stream creation) instead of priority/reliability fields. Data payload is up to 16,000 bits (multiple of 16 bits).