[Docs] [txt|pdf] [Tracker]
Updated by: 1221 INTERNET STANDARD
RFC 907
HOST ACCESS PROTOCOL SPECIFICATION
July 1984
prepared for
Defense Advanced Research Projects Agency
1400 Wilson Boulevard
Arlington, Virginia 22209
by
Bolt Beranek and Newman Laboratories
10 Moulton Street
Cambridge, Massachusetts 02238
RFC 907 Host Access Protocol
July 1984 Specification
Preface (Status of this Memo)
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
between hosts and packet-switched satellite networks such as
SATNET and TACNET (aka MATNET) as well as the Wideband Network.
The HAP specification presented here is a minor revision of, and
supercedes, the specification presented in Chapter 4 of BBN
Report No. 4469, the "PSAT Technical Report". As such, the
details of the current specification are still most closely
matched to the characteristics if the Wideband Satellite Network.
Revisions to the specification in the "PSAT Technical Report"
include the definition of three new control message types
(Loopback Request, Link Going Down, and NOP), a "Reason" field in
Restart Request control messages, new Unnumbered Response codes,
and new values for the setup codes used to manage streams and
groups.
HAP is an experimental protocol, and will undergo further
revision as new capabilities are added and/or different satellite
networks are supported. Implementations of HAP should be
performed in coordination with satellite network development and
operations personnel.
RFC 907 Host Access Protocol
July 1984 Specification
Table of Contents
1 Introduction.......................................... 1
2 Overview.............................................. 3
3 Datagram Messages..................................... 8
4 Stream Messages...................................... 14
5 Flow Control Messages................................ 17
6 Setup Level Messages................................. 24
6.1 Stream Setup Messages.............................. 32
6.2 Group Setup Messages............................... 44
7 Link Monitoring...................................... 58
8 Initialization....................................... 62
9 Loopback Control..................................... 68
10 Other Control Messages.............................. 72
i
RFC 907 Host Access Protocol
July 1984 Specification
FIGURES
DATAGRAM MESSAGE.......................................... 9
STREAM MESSAGE........................................... 15
ACCEPTANCE/REFUSAL WORD.................................. 19
ACCEPTANCE/REFUSAL MESSAGE............................... 21
UNNUMBERED RESPONSE...................................... 22
SETUP MESSAGE HEADER..................................... 26
NOTIFICATION MESSAGE..................................... 29
SETUP ACKNOWLEDGMENT..................................... 31
STREAM EXAMPLE........................................... 33
CREATE STREAM REQUEST.................................... 35
CREATE STREAM REPLY...................................... 37
CHANGE STREAM PARAMETERS REQUEST......................... 39
CHANGE STREAM PARAMETERS REPLY........................... 41
DELETE STREAM REQUEST.................................... 42
DELETE STREAM REPLY...................................... 43
GROUP EXAMPLE............................................ 45
CREATE GROUP REQUEST..................................... 47
CREATE GROUP REPLY....................................... 48
JOIN GROUP REQUEST....................................... 50
JOIN GROUP REPLY......................................... 52
LEAVE GROUP REQUEST...................................... 53
LEAVE GROUP REPLY........................................ 55
DELETE GROUP REQUEST..................................... 56
DELETE GROUP REPLY....................................... 57
STATUS MESSAGE........................................... 59
HAP LINK RESTART STATE DIAGRAM........................... 64
RESTART REQUEST.......................................... 65
RESTART COMPLETE......................................... 67
LOOPBACK REQUEST......................................... 71
LINK GOING DOWN.......................................... 73
NO OPERATION (NOP)....................................... 75
ii
RFC 907 Host Access Protocol
July 1984 Specification
1 Introduction
The Host Access Protocol (HAP) specifies the network-access
level communication between an arbitrary computer, called a host,
and a packet-switched satellite network. The satellite network
provides message delivery services for geographically separated
hosts: Messages containing data which are meaningful to the hosts
are submitted to the network by an originating (source) host, and
are passed transparently through the network to an indicated
destination host. To utilize such services, a host interfaces to
the satellite network via an access link to a dedicated packet-
switching computer, known as a Satellite Interface Message
Processor (Satellite IMP or SIMP). HAP defines the different
types of control messages and (host-to-host) data messages that
may be exchanged over the access link connecting a host and a
SIMP. The protocol establishes formats for these messages, and
describes procedures for determining when each type of message
should be transmitted and what it means when one is received.
The term "Interface Message Processor" originates in the
ARPANET, where it refers to the ARPANET's packet-switching nodes.
SIMPs differ from ARPANET IMPs in that SIMPs form a network via
connections to a common multiaccess/broadcast satellite channel,
whereas ARPANET IMPs are interconnected by dedicated point-to-
point terrestrial communications lines. This fundamental
difference between satellite-based and ARPANET-style networks
results in different mechanisms for the delivery of messages from
source to destination hosts and for internal network
coordination. Additionally, satellite networks tend to offer
different type of service options to their connected hosts than
do ARPANET-style networks. These options are included in the
Host Access Protocol presented here.
Several types of Satellite IMPs have been developed on a
variety of processors for the support of three different packet-
switched satellite networks. The original SIMP was employed in
the Atlantic Packet Satellite Network (SATNET). It was developed
from one of the models of ARPANET IMP, and was implemented on a
Honeywell 316 minicomputer. The 316 SIMPs were succeeded in
SATNET by SIMPs based on BBN C/30 Communications Processor
hardware. The C/30 SIMPs have also been employed in the Mobile
1
RFC 907 Host Access Protocol
July 1984 Specification
Access Terminal Network (MATNET). The SATNET and MATNET SIMPs
implement a network-access level protocol known as Host/SATNET
Protocol. Host/SATNET Protocol is the precursor to HAP and is
documented in Internet Experiment Note (IEN) No. 192. The
Wideband Satellite Network, like SATNET, has undergone an
evolution in the development of its SIMP hardware and software.
The original Wideband Network SIMP is known as the Pluribus
Satellite IMP, or PSAT, having been implemented on the BBN
Pluribus Multiprocessor. Its successor, the BSAT, is based on
the BBN Butterfly Multiprocessor. Both the PSAT and the BSAT
communicate with their connected network hosts via HAP.
Section 2 presents an overview of HAP. Details of HAP
formats and message exchange procedures are contained in Sections
3 through 10. Further explanation of many of the topics
addressed in this HAP specification can be found in BBN Report
No. 4469, the "PSAT Technical Report".
The protocol used to provide sufficiently reliable message
exchange over the host-SIMP link is assumed to be transparent to
the network-access protocol defined in this document. Examples
of such link-level protocols are ARPANET 1822 local and distant
host, ARPANET VDH protocol, and HDLC.
2
RFC 907 Host Access Protocol
July 1984 Specification
2 Overview
HAP can be characterized as a full duplex nonreliable
protocol with an optional flow control mechanism. HAP messages
flow simultaneously in both directions between the SIMP and the
host. Transmission is nonreliable in the sense that the protocol
does not provide any guarantee of error-free sequenced delivery.
To the extent that this functionality is required on the access
link (e.g., non-collocated SIMP and host operating over a
communication circuit), it must be supported by the link-level
protocol below HAP. The flow control mechanism operates
independently in each direction except that enabling or disabling
the mechanism applies to both sides of the interface.
HAP supports host-to-host communication in two modes
corresponding to the two types of HAP data messages, datagram
messages and stream messages. Each type of message can be up to
approximately 16K bits in length. Datagram messages provide the
basic transmission service in the satellite network. Datagram
messages transmitted by a host experience a nominal two satellite
hop end-to-end network delay. (Note that this delay, of about 0.6
sec excluding access link delay, is associated with datagram
transmission between hosts on different SIMPs. The transmission
delay between hosts on the same SIMP will be much smaller
assuming the destination is not a group address. See Section 3
and 6.2.) A datagram control header, passed to the SIMP by the
host along with message text, determines the processing of the
message within the satellite network independent of any previous
exchanges.
Stream messages provide a one satellite hop delay
(approximately 0.3 sec) for volatile traffic, such as speech,
which cannot tolerate the delay associated with datagram
transmission. Hosts may also use streams to support high duty
cycle applications which require guaranteed channel bandwidth.
Host streams are established by a setup message exchange between
the host and the network prior to the commencement of data flow.
Although established host streams can have their characteristics
modified by subsequent setup messages while they are in use, the
fixed allocation properties of streams relative to datagrams
impose rather strict requirements on the source of the traffic
3
RFC 907 Host Access Protocol
July 1984 Specification
using the stream. Stream traffic arrivals must match the stream
allocation both in interarrival time and message size if
reasonable efficiency is to be achieved. The characteristics and
use of datagrams and streams are described in detail in Sections
3 and 4 of this document.
Both datagram and stream transmission in the satellite
network use logical addressing. Each host on the network is
assigned a permanent 16-bit logical address which is independent
of the physical port on the SIMP to which it is attached. These
16-bit logical addresses are provided in all Host-to-SIMP and
SIMP-to-Host data messages.
Hosts may also be members of groups. Group addressing is
provided primarily to support the multi-destination delivery
required for conferencing applications. Like streams, group
addresses are dynamically created and deleted by the use of setup
messages exchanged between a host and the network. Membership in
a group may consist of an arbitrary subset of all the permanent
network hosts. A message addressed to a group address is
delivered to all hosts that are members of that group.
Although HAP does not guarantee error-free delivery, error
control is an important aspect of the protocol design. HAP error
control is concerned with both local transfers between a host and
its local SIMP and transfers from SIMP-to-SIMP over the satellite
channel. The SIMP offers users a choice of network error
protection options based on the network's ability to selectively
send messages over the satellite channel at different coding
rates. These forward error correction (FEC) options are referred
to as reliability levels. Three reliability levels (low, medium,
and high) are available to the host.
In addition to forward error correction, a number of
checksum mechanisms are employed in the satellite network to add
an error detection capability. A host has an opportunity when
sending a message to indicate whether the message should be
delivered to its destination or discarded if a data error is
detected by the network. Each message received by a host from
the network will have a flag indicating whether or not an error
was detected in that particular message. A host can decide on a
4
RFC 907 Host Access Protocol
July 1984 Specification
per-message basis whether or not it wants to accept or discard
transmissions containing data errors.
For connection of a host and SIMP in close proximity, error
rates due to external noise or hardware failures on the access
circuit may reasonably be expected to be much smaller than the
best satellite channel error rate. Thus for this case, little is
gained by using error detection and retransmission on the access
circuit. A 16-bit header checksum is provided, however, to
insure that SIMPs do not act on incorrect control information.
For relatively long distances or noisy connections,
retransmissions over the access circuit may be required to
optimize performance for both low and high reliability traffic.
It is expected that link-level error control procedures (such as
HDLC) will be used for this purpose.
Datagram and stream messages being presented to the network
by a host may not be accepted for a number of reasons: priority
too low, destination dead, lack of buffers in the source SIMP,
etc. The host faces a similar situation with respect to handling
messages from the SIMP. To permit the receiver of a message to
inform the sender of the local disposition of its message, an
acceptance/refusal (A/R) mechanism is implemented. The mechanism
is the external manifestation of the SIMP's (or host's) internal
flow and congestion control algorithm. If A/Rs are enabled, an
explicit or implicit acceptance or refusal for each message is
returned to the host by the SIMP (and conversely). This allows
the host (or SIMP) to retry refused messages at its discretion
and can provide information useful for optimizing the sending of
subsequent messages if the reason for refusals is also provided.
The A/R mechanism can be disabled to provide a "pure discard"
interface.
Each message submitted to the SIMP by a host is marked as
being in one of four priority classes, from priority 3 (highest)
through priority 0 (lowest). The priority class is used by the
SIMP for arbitrating contention for scarce network resources
(e.g., channel time). That is, if the network cannot deliver all
of the offered messages, high priority messages will be delivered
in preference to low priority messages. In the case of
datagrams, priority level is used by the SIMP for ordering
5
RFC 907 Host Access Protocol
July 1984 Specification
satellite channel reservation requests at the source SIMP and
message delivery at the destination SIMP. In the case of
streams, priority is associated with the ability of one stream to
preempt another stream of lower priority at setup time.
While the A/R mechanism allows control of individual message
transfers, it does not facilitate regulation of priority flows.
Such regulation is handled by passing advisory status information
(GOPRI) across the Host-SIMP interface indicating which
priorities are currently being accepted. As long as this
information, relative to the change in priority status, is passed
frequently, the sender can avoid originating messages which are
sure to be refused.
HAP defines both data messages (datagram messages and stream
messages) and control messages. Data messages are used to send
information between network hosts. Control messages are
exchanged between a host and the network to manage the local
access link. HAP can also be viewed in terms of two distinct
protocol layers, the message layer and the setup layer. The
message layer is associated with the transmission of individual
datagram messages and stream messages. The setup layer protocol
is associated with the establishment, modification, and deletion
of streams and groups. Setup layer exchanges are actually
implemented as datagrams transmitted between the user host and an
internal SIMP "service host."
Every HAP message consists of an integral number of 16-bit
words. The first several words of the message always contain
control information and are referred to as the message header.
The first word of the message header identifies the type of
message which follows. The second word of the message header is
a checksum which covers all header information. Any message
whose received header checksum does not match the checksum
computed on the received header information must be discarded.
The format of the rest of the header depends on the specific
message type.
The formats and use of the individual message types are
detailed in the following sections. A common format description
is used for this purpose. Words in a message are numbered
6
RFC 907 Host Access Protocol
July 1984 Specification
starting at zero (i.e., zero is the first word of a message
header). Bits within a word are numbered from zero (least
significant) to fifteen (most significant). The notation used to
identify a particular field location is:
<WORD#>{-<WORD#>} [ <BIT#>{-<BIT#>} ] <description>
where optional elements in {} are used to specify the (inclusive)
upper limit of a range. The reader should refer to these field
identifiers for precise field size specifications. Fields which
are common to several message types are defined in the first
section which uses them. Only the name of the field will usually
appear in the descriptions in subsequent sections.
Link-level protocols used to support HAP can differ in the
order in which they transmit the bits constituting HAP messages.
For HDLC and ARPANET VDH, each word of a HAP message is
transmitted starting with the least significant bit (bit 0) and
ending with the most significant bit (bit 15). The words of the
message are transmitted from word 0 to word N. For ARPANET 1822
local and distant host interfaces, the order of bit transmission
within each word is the reverse of that for HDLC and VDH, i.e.,
the transmission is from bit 15 to bit 0.
7
RFC 907 Host Access Protocol
July 1984 Specification
3 Datagram Messages
Datagram messages are one of the two types of message level
data messages used to support host-to-host communication. Each
datagram can contain up to 16,384 bits of user data. Datagram
messages transmitted by a host to a host on a remote SIMP
experience a nominal two satellite hop end-to-end network delay
(about 0.6 sec), excluding delay on the access links. This
network delay is due to the reservation per message scheduling
procedure for datagrams which only allocates channel time to the
message for the duration of the actual transfer. Since datagram
transfers between permanent hosts on the same SIMP do not require
satellite channel scheduling prior to data transmission, the
network delay in this case will be much smaller and is determined
strictly by SIMP processing time. Datagrams sent to group
addresses are treated as if they were addressed to remote hosts
and are always sent over the satellite channel. It is expected
that datagram messages will be used to support the majority of
computer-to-computer and terminal-to-computer traffic which is
bursty in nature.
The format of datagram messages and the purpose of each of
the header control fields is described in Figure 1.
8
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| XXXX | F| MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 0|IL| D| E| TTL | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 1 . DATAGRAM MESSAGE
0[15] Message Class. This bit identifies the message as a
data message or a control message.
0 = Data Message
1 = Control Message
0[14] Loopback Bit. This bit allows the sender of a message
to determine if its own messages are being looped back.
The host and the SIMP each use different settings of
this bit for their transmissions. If a message arrives
with the loopback bit set equal to its outgoing value,
then the message has been looped.
0 = Sent by Host
1 = Sent by SIMP
9
RFC 907 Host Access Protocol
July 1984 Specification
0[12-13] Go-Priority. In SIMP-to-Host messages, this field
provides advisory information concerning the lowest
priority currently being accepted by the SIMP. The
host may optionally choose to provide similar priority
information to the SIMP.
0 = Low Priority
1 = Medium-Low Priority
2 = Medium-High Priority
3 = High Priority
0[9-11] Reserved.
0[8] Force Channel Transmission Flag. This flag can be set
by the source host to force the SIMP to transmit the
message over the satellite channel even if the message
contains permanent destination and source host
addresses corresponding to hosts which are physically
connected to the same SIMP.
0 = Normal operation
1 = Force channel transmission
0[0-7] Message Number. This field contains the identification
of the message used by the acceptance/refusal (A/R)
mechanism (when enabled). If the message number is
zero, A/R is disabled for this specific message. See
Section 5 for a detailed description of the A/R
mechanism.
1[0-15] Header Checksum. This field contains a checksum which
covers words 0-5. It is computed as the negation of
the 2's-complement sum of words 0-5 (excluding the
checksum word itself).
2[0-15] Piggybacked A/R. This field may contain an
acceptance/refusal word providing A/R status on traffic
flowing in the opposite direction. Its inclusion may
eliminate the need for a separate A/R control message
(see Section 5). A value of zero for this word is used
to indicate that no piggybacked A/R information is
10
RFC 907 Host Access Protocol
July 1984 Specification
present.
3[15] Data Message Type. This bit identifies whether the
message is a datagram message or a stream message.
0 = Datagram Message
1 = Stream Message
3[14] Internet/Local Flag. This flag is set by a source host
to specify to a destination host whether the data
portion of the message contains a standard DoD Internet
header. This field is passed transparently by the
source and destination SIMPs for traffic between
external satellite network hosts. This field is
examined by internal SIMP hosts (e.g., the network
service host) in order to support Internet operation.
0 = Internet
1 = Local
3[13] Discard Flag. This flag allows a source host to
instruct the satellite network (including the
destination host) what to do with the message when data
errors are detected (assuming the header checksum is
correct).
0 = Discard message if data errors detected.
1 = Don't discard message if data errors detected.
The value of this flag, set by the source host, is
passed on to the destination host.
3[12] Data Error Flag. This flag is used in conjunction with
the Discard Flag to indicate to the destination host
whether any data errors have been detected in the
message prior to transmission over the SIMP-to-Host
access link. It is used only if Discard Flag = 1. It
should be set to zero by the source host.
11
RFC 907 Host Access Protocol
July 1984 Specification
0 = No Data Errors Detected
1 = Data Errors Detected
3[10-11] Time-to-Live Designator. The source host uses this
field to specify the maximum time that a message
should be allowed to exist within the satellite network
before being deleted. Messages may be discarded by the
network prior to this maximum elapsed time.
0 = 1 seconds
1 = 2 seconds
2 = 5 seconds
3 = 10 seconds
The Time-to-Live field is undefined in messages sent
from a SIMP to a host.
3[8-9] Priority. The source host uses this field to specify
the priority with which the message should be handled
within the network.
0 = Low Priority
1 = Medium-Low Priority
2 = Medium-High Priority
3 = High Priority
The priority of each message is passed to the
destination host by the destination SIMP.
3[6-7] Reliability. The source host uses this field to
specify the basic bit error rate requirement for the
data portion of this message. The source SIMP uses
this field to determine the satellite channel
transmission parameters required to provide that bit
error rate.
0 = Low Reliability
1 = Medium Reliability
12
RFC 907 Host Access Protocol
July 1984 Specification
2 = High Reliability
3 = Reserved
The Reliability field is undefined in messages sent
from a SIMP to a host.
3[0-5] Reliability Length. This source host uses this field
to specify a portion of the user data which should be
transmitted at the highest reliability level (lowest
bit error rate). Both the six message header words and
the first Reliability Length words of user data will be
transmitted at Reliability=2 while the remainder of the
user data will be transmitted at whatever reliability
level is specified in field 3[6-7]. The reliability
length mechanism gives the user the ability to transmit
private header information (e.g., IP and TCP headers)
at a higher reliability level than the remainder of the
data. The Reliability Length field is undefined in
messages sent from a SIMP to a host.
4[0-15] Destination Host Address. This field contains the
satellite network logical address of the destination
host.
5[0-15] Source Host Address. This field contains the satellite
network logical address of the source host.
6-N Data. This field contains up to 16,384 bits (1024 16-
bit words) of user data.
13
RFC 907 Host Access Protocol
July 1984 Specification
4 Stream Messages
Stream messages are the second type of message level data
messages. As noted in Section 2, streams exist primarily to
provide a one satellite hop delay for volatile traffic such as
speech. Hosts may also use streams to support high duty cycle
applications which require guaranteed channel bandwidth.
Streams must be created before stream messages can flow from
host to host. The protocol to accomplish stream creation is
described in Section 6.1. Once established, a stream is
associated with a recurring channel allocation within the
satellite network. This fixed allocation imposes rather strict
requirements on the host using the stream if efficient channel
utilization is to be achieved. In particular, stream messages
must match the stream allocation both in terms of message size
and message interarrival time.
Within the bounds of its stream allocation, a host is
permitted considerable flexibility in how it may use a stream.
Although the priority, reliability, and reliability length of
each stream message is fixed at stream creation time, the
destination logical address can vary from stream message to
stream message. A host can, therefore, multiplex a variety of
logical flows onto a single host stream. The format of stream
messages is described in Figure 2.
14
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 0|LB|GOPRI| XXXX | MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | 1|IL| D| E| TTL | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | DESTINATION HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SOURCE HOST ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 2 . STREAM MESSAGE
0[15] Message Class = 0 (Data Message).
0[14] Loopback Bit.
0[12-13] Go-Priority.
0[8-11] Reserved.
0[0-7] Message Number. This field serves the same purpose as
the message number field in the datagram message.
Moreover, a single message number sequence is used for
both datagram and stream messages (see Section 5).
1[0-15] Header Checksum. Covers Words 0-5.
2[0-15] Piggybacked A/R.
15
RFC 907 Host Access Protocol
July 1984 Specification
3[15] Data Message Type = 1 (Stream).
3[14] Internet/Local Flag.
3[13] Discard Flag.
3[12] Data Error Flag.
3[10-11] Time-to-live Designator.
0 = Reserved
1 = 1 second
2 = Reserved
3 = Reserved
3[0-9] Host Stream ID. The service host uses this field to
identify the host stream over which the message is to
be sent by the SIMP. Host stream IDs are established
at stream creation time via host exchanges with their
network service host (see Section 6.1).
4[0-15] Destination Host Address.
5[0-15] Source Host Address.
6-N Data. This field contains up to 16,000 bits of user
data (multiple of 16-bits).
16
RFC 907 Host Access Protocol
July 1984 Specification
5 Flow Control Messages
The SIMP supports an acceptance/refusal (A/R) mechanism in
each direction on the host access link. The A/R mechanism is
enabled for the link by the host by setting a bit in the Restart
Complete control message (see Section 8). Each datagram and
stream message contains an 8-bit message number used to identify
the message for flow control purposes. Both the host and the
SIMP increment this number modulo 256 in successive messages they
transmit. Up to 127 messages may be outstanding in each
direction at any time. If the receiver of a message is unable to
accept the message, a refusal indication containing the message
number of the refused message and the reason for the refusal is
returned. The refusal indication may be piggybacked on data
messages in the opposite direction over the link or may be sent
in a separate control message in the absence of reverse traffic.
Acceptance indications are returned in a similar manner,
either piggybacked on data messages or in a separate control
message. An acceptance is returned by the receiver to indicate
that the identified message was not refused. Acceptance
indications returned by the SIMP do not, however, imply a
guarantee of delivery or even any assurance that the message will
not be intentionally discarded by the network at a later time.
They are sent primarily to facilitate buffer management in the
host.
To reduce the number of A/R messages exchanged, a single A/R
indication can be returned for multiple (lower numbered)
previously unacknowledged messages. Explicit acceptance of
message number N implies implicit acceptance of outstanding
messages with numbers N-1, N-2, etc., according to the
definition of acceptance outlined above. (Note that explicit
acceptance of message number N does not imply that all of the
unacknowledged outstanding messages have been received.) An
analogous interpretation of refusal message number allows the
receiver of a group of messages to reject them as a group
assuming that they all are being refused for the same reason. As
a further efficiency measure, HAP permits a block of A/R
indications to be aggregated into a single A/R control message.
Such a message might be used, for example, to reject a group of
17
RFC 907 Host Access Protocol
July 1984 Specification
messages where the refusal code on each is different.
In some circumstances the overhead associated with
processing A/R messages may prove unattractive. For these cases,
it is possible to disable the A/R mechanism and operate the HAP
interface in a purely discard mode. The ability to effect this
on a link basis has already been noted (see Sections 2 and 8).
In addition, messages with sequence number zero are taken as
messages for which the A/R mechanism is selectively disabled. To
permit critical feedback, even when operating in discard mode,
HAP defines an "Unnumbered Response" control message.
The format shown in Figure 3 is used both for piggybacking
A/R indications on data messages (word 2), and for providing A/R
information in separate control messages. When separate control
messages are used to transmit A/R indications, the format shown
in Figure 4 applies. Flow control information and other
information which cannot be sent as an A/R indication is sent in
an Unnumbered Response control message. The format of this type
of message is illustrated in Figure 5.
18
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|AR| REFUSAL CODE | A/R MESSAGE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3 . ACCEPTANCE/REFUSAL WORD
[15] Acceptance/Refusal Type. This field identifies whether
A/R information is an acceptance or a refusal.
0 = Acceptance
1 = Refusal
[8-14] Refusal Code. When the Acceptance/Refusal Type = 1,
this field gives the Refusal Code.
0 = Priority not being accepted
1 = Source SIMP congestion
2 = Destination SIMP congestion
3 = Destination host dead
4 = Destination SIMP dead
5 = Illegal destination host address
6 = Destination host access not allowed
7 = Illegal source host address
8 = Message lost in access link
9 = Nonexistent stream ID
10 = Illegal source host for stream ID
11 = Message length too long
12 = Stream message too early
13 = Illegal control message type
14 = Illegal refusal code in A/R
15 = Illegal reliability value
16 = Destination host congestion
[0-7] A/R Message Number. This field contains the number of
19
RFC 907 Host Access Protocol
July 1984 Specification
the message to which this acceptance/refusal refers.
It also applies to all outstanding messages with
earlier numbers. Note that this field can never be
zero since a message number of zero implies that the
A/R mechanism is disabled.
20
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXX | LENGTH | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
. . ... .
. . ... .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N | A/R |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 4 . ACCEPTANCE/REFUSAL MESSAGE
0[15] Message Class = 1 (Control Message).
0[14] Loopback Bit.
0[12-13] Go-Priority.
0[8-11] Reserved.
0[4-7] Message Length. This field contains the total length
of this message in words (N+1).
0[0-3] Control Message Type = 1 (Acceptance/Refusal).
1[0-15] Header Checksum. The checksum covers words 0-N.
2[0-15] Acceptance/Refusal Word.
3-N Additional Acceptance/Refusal Words (optional).
21
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXX | RES-CODE | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | RESPONSE INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 5 . UNNUMBERED RESPONSE
0[15] Message Class = 1 (Control Message).
0[14] Loopback Bit.
0[12-13] Go-Priority.
0[8-11] Reserved.
0[4-7] Response Code.
3 = Destination unreachable
5 = Illegal destination host address
7 = Illegal source host address
9 = Nonexistent stream ID
10 = Illegal stream ID
13 = Protocol violation
15 = Can't implement loop
0[0-3] Control Message Type = 5 (Unnumbered Response).
1[0-15] Header Checksum. Covers words 0-3.
22
RFC 907 Host Access Protocol
July 1984 Specification
2[0-15] Response Information. If Response Code is:
3, Destination Host Address
5, Destination Host Address
7, Source Host Address
9, Stream ID (right justified)
10, Stream ID (right justified)
13, Word 0 of offending message
15, Word 0 of Loopback Request message
3[0-15] Response Information. If Response Code is:
3,5,7, or 9. Undefined
10, Source Host Address
13, Word 3 of offending message, or zero if
no word 3
15, Word 2 of Loopback Request message
23
RFC 907 Host Access Protocol
July 1984 Specification
6 Setup Level Messages
Setup level protocol is provided to support the
establishment, modification, and deletion of groups and streams
in the packet satellite network. A host wishing to perform one
of these generic operations interacts with the network service
host (logical address zero). The service host causes the
requested action to be carried out and serves as the intermediary
between the user and the rest of the network. In the process of
implementing the requested action, various network data bases are
updated to reflect the current state of the referenced group or
stream.
The communication between the host and the service host is
implemented via special-purpose datagrams called setup messages.
Each interaction initiated by a host involves a 3-way exchange
where: (1) the user host sends a Request to the service host, (2)
the service host returns a Reply to the user host, and (3) the
user host returns a Reply Acknowledgment to the service host.
This procedure is used to insure reliable transmission of
requests and replies. In order to allow more than one setup
request message from a host to be outstanding, each request is
assigned a unique Request ID. The associated Reply and
subsequent Reply Acknowledgment are identified by the Request ID
that they contain. Hosts should generally expect a minimum delay
of about two satellite round-trip times between the transmission
of a setup Request to the SIMP and the receipt of the associated
Reply. (Note that the Join Group Request and the Leave Group
Request require only local communication between a host and its
SIMP. The response time for these requests, therefore, is
dependent solely on SIMP processing time and should be
considerably shorter than two round-trip times.) This delay
establishes a maximum rate at which changes can be processed by
the SIMP. The user should receive a reply to a setup request
requiring global communication within 2 seconds and to a setup
request requiring local communication within 1 second. The host
should respond to a SIMP Reply with a Reply Acknowledgment within
1 second.
24
RFC 907 Host Access Protocol
July 1984 Specification
Setup exchanges can also be initiated by the SIMP. SIMP-
initiated setup messages are used to notify a host of changes in
the status of an associated group or stream. Each notification
involves a 2-way exchange where: (1) the service host sends a
Notification to the user host, and (2) the user host returns a
Notification Acknowledgment to the service host. In order to
allow more than one Notification to be outstanding, each is
assigned a unique Notification ID. The Notification
Acknowledgment returned by the user host to the service host must
contain the Notification ID.
The general format of every setup message is:
<DATAGRAM MESSAGE HEADER>
<OPTIONAL INTERNET HEADER>
<SETUP MESSAGE HEADER>
<SETUP MESSAGE BODY>
The service host accepts setup requests in either Internet or
non-Internet format. Replies from the service host will be in
the same form as the request, that is, Internet requests get
Internet replies, and non-Internet requests get non-Internet
replies.
The format of the combined datagram message header and setup
message header is illustrated in Figure 6. The body of the setup
messages depends on the particular setup message type. Stream
request and reply messages are described in Section 6.1. Group
request and reply messages are described in Section 6.2. To
simplify the presentation in both of these sections, the setup
messages are assumed to be exchanged between a local host and
SIMP even though Internet group and stream setups are supported
(see Figure 6). The format of notifications, which consists of
only a single word beyond the basic setup header, is shown in
Figure 7. Since the SIMP does not retain the optional Internet
header information that can be included in setup requests,
Internet notifications are not supported. The format of
acknowledgment messages associated with request/reply and
notification setups is illustrated in Figure 8.
25
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6-N | <OPTIONAL INTERNET HEADER> |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+1 | SETUP TYPE | SETUP CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+2 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
N+3 | SETUP ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 6 . SETUP MESSAGE HEADER
0-5 Datagram Message Header. Each setup message begins
with the six word datagram message header (see Section
3).
6-N Internet Header (Optional). These fields, when
present, conform to the DoD Standard Internet Protocol
(IP). The Internet header size is a minimum of 10
words but can be longer depending on the use of
optional IP facilities. (Internet notification
messages are not supported.)
N+1[8-15] Setup Type. This field determines the type of setup
message.
0 = Acknowledgment
1 = Request
2 = Reply
3 = Notification
N+1[0-7] Setup Code. For requests, this field identifies the
26
RFC 907 Host Access Protocol
July 1984 Specification
Request Type.
1 = Create group address
2 = Delete group address
3 = Join group
4 = Leave group
5 = Create stream
6 = Delete stream
7 = Change stream parameters
8 = Reserved
For Replies, this field provides the Reply Code. Some
of the Reply Codes can be returned to any setup
request and others are request specific.
0 = Group or stream created
1 = Group or stream deleted
2 = Group joined
3 = Group left
4 = Stream changed
5 = Reserved
6 = Bad request type
7 = Reserved
8 = Network trouble
9 = Bad key
10 = Group address/stream ID nonexistent
11 = Not member of group/creator of stream
12 = Stream priority not being accepted
13 = Reserved
14 = Reserved
15 = Illegal interval
16 = Reserved
17 = Insufficient network resources
18 = Requested bandwidth too large
19 = Reserved
20 = Reserved
21 = Maximum messages per slot not consistent with
slot size
22 = Reply lost in network
23 = Illegal reliability value
27
RFC 907 Host Access Protocol
July 1984 Specification
For Notifications, this field contains the
Notification Type.
0 = Stream suspended
1 = Stream resumed
2 = Stream deleted
3 = Group deleted by host
4 = Group deleted by SIMP
5 = All streams deleted
6 = All groups deleted
For Acknowledgments, this field contains the
Acknowledgment Type.
0 = Reply acknowledgment
1 = Notification acknowledgment
N+2[0-15] Setup Checksum. The checksum covers the three setup
message header words and the setup message body data
words. Setups received with bad checksums must be
discarded.
N+3[0-15] Setup ID. This field is assigned by the host to
uniquely identify outstanding requests (Request ID)
and by the service host to uniquely identify
outstanding notifications (Notification ID).
28
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 3 | NOTIFICATION TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | NOTIFICATION ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | NOTIFICATION INFO |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 7 . NOTIFICATION MESSAGE
0-5 Datagram Message Header (see Section 3).
6[8-15] Setup Type = 3 (Notification).
6[0-7] Notification Type.
0 = Stream suspended
1 = Stream resumed
2 = Stream deleted
3 = Group deleted by host
4 = Group deleted by SIMP
5 = All streams deleted
6 = All groups deleted
7[0-15] Setup Checksum. Covers words 6-9.
8[0-15] Notification ID.
9[0-15] Notification Information. This field contains the
16-bit group address in the case of a group
29
RFC 907 Host Access Protocol
July 1984 Specification
notification (types 3 and 4) and the 10-bit host
stream ID (right justified) in the case of a stream
notification (types 0-2). This field is zero for
Notification Types 5 and 6, which pertain to ALL
streams and groups, respectively.
30
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 0 | ACK TYPE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | SETUP ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 8 . SETUP ACKNOWLEDGMENT
0-5 Datagram Message Header.
6[8-15] Setup Type = 0 (Acknowledgment).
6[0-7] Acknowledgment Type.
0 = Reply acknowledgment
1 = Notification acknowledgment
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Setup ID. This is either a Request ID or a
Notification ID.
31
RFC 907 Host Access Protocol
July 1984 Specification
6.1 Stream Setup Messages
Hosts use streams to support high duty cycle applications
and applications requiring a one satellite hop network
transmission delay. Host streams must be set up before stream
data messages can flow. The stream setup messages defined by HAP
are Create Stream Request, Create Stream Reply, Delete Stream
Request, Delete Stream Reply, Change Stream Parameters Request,
and Change Stream Parameters Reply. The use of these messages is
illustrated in the scenario of exchanges between a host and its
local SIMP shown in Figure 9 where the host establishes a stream,
sends some data, modifies the stream characteristics, sends some
more data, and finally closes down the stream.
It is worthwhile noting that the setup exchanges in Figure 9
are completely between the host originating the stream and its
local SIMP. Other SIMPs and hosts are essentially unaware of the
existence of the stream. Stream messages received by a
destination host are, therefore, processed identically to
datagram messages. (All SIMPs must, of course, be aware of the
channel allocation associated with a host stream in order to
perform satellite channel scheduling.) Not illustrated, but
implicit in this scenario, are the optional A/R indications
associated with each of the stream setup messages.
32
RFC 907 Host Access Protocol
July 1984 Specification
Host SIMP
Create Stream Request ------>
Create Stream Reply <------
Reply Acknowledgment ------>
Stream Message ------>
.
.
Stream Message ------>
Change Stream Parameters Request ------>
Change Stream Parameters Reply <------
Reply Acknowledgment ------>
Stream Message ------>
.
.
Stream Message ------>
Delete Stream Request ------>
Delete Stream Reply <------
Reply Acknowledgment ------>
Figure 9 . STREAM EXAMPLE
Host streams have six characteristic properties which are
selected at stream setup time. These properties, which apply to
every message transmitted in the stream, are: (1) slot size, (2)
interval, (3) reliability, (4) reliability length, (5) priority,
and (6) maximum messages per slot. To establish a stream, the
host sends the Create Stream Request message illustrated in
Figure 10 to the SIMP. After the satellite network has processed
the Create Stream Request, the SIMP will respond to the host with
a Create Stream Reply message formatted as shown in Figure 11.
Assuming that the reply code in the Create Stream Reply is zero
indicating that the stream has been created successfully, the
host may proceed to transmit stream data messages after sending a
33
RFC 907 Host Access Protocol
July 1984 Specification
Reply Acknowledgment.
During the lifetime of a stream, the host which created it
may decide that some of its six characteristic properties should
be modified. All of the properties except the stream interval
can be modified using the Change Stream Parameters Request
message. The format of this command is illustrated in Figure 12.
After the network has processed the Change Stream Parameters
Request, the SIMP will respond by sending a Change Stream
Parameters Reply to the host with the format shown in Figure 13.
A host requesting a reduced channel allocation should decrease
its sending rate immediately without waiting for receipt of the
Change Stream Parameters Reply. A host requesting an increased
allocation should not proceed to transmit according to the new
set of parameters without first having received a Reply Code of 4
indicating that the requested change has taken effect.
When the host which created the host stream determines that
the stream is no longer needed and the associated satellite
channel allocation can be freed up, the host sends its local SIMP
a Delete Stream Request message formatted as indicated in Figure
14. After the network has processed the Delete Stream Request,
the SIMP will respond by sending a Delete Stream Reply to the
host with the format shown in Figure 15.
34
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 5 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | MAX MES | INT | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | SLOT SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 10 . CREATE STREAM REQUEST
0-5 Datagram Message Header.
6[8-15] Setup Type = 1 (Request).
6[0-7] Request Type = 5 (Create Stream).
7[0-15] Setup Checksum. Covers words 6-10.
8[0-15] Request ID.
9[12-15] Maximum Messages Per Slot. This field specifies the
the maximum number of stream messages that will ever
be delivered to the SIMP by the host for transmission
in one stream slot.
9[10-11] Interval. This field specifies the interval, in
number of 21.2 ms frames, between stream slots.
35
RFC 907 Host Access Protocol
July 1984 Specification
0 = 1 frame
1 = 2 frames
2 = 4 frames
3 = 8 frames
As an example, an interval of 4 frames corresponds to
an allocation of Slot Size words every 85 ms.
9[8-9] Priority. This field specifies the priority at which
all messages in the host stream should be handled.
0 = Low priority
1 = Medium Low Priority
2 = Medium High Priority
3 = High Priority
9[6-7] Reliability. This field specifies the basic bit-
error rate requirement for the data portion of all
messages in the host stream.
0 = Low Reliability
1 = Medium Reliability
2 = High Reliability
3 = Reserved
9[0-5] Reliability Length. This field specifies how many
words beyond the stream message header should be
transmitted at maximum reliability for all messages
in the host stream.
10[0-15] Slot Size. This field specifies the slot size in
16-bit words of stream message text. Stream message
header words are excluded from this count. The host
can partition this allocation on a slot-by-slot basis
among a variable number of messages as long as the
maximum number of messages per slot does not exceed
MAX MES.
36
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 11 . CREATE STREAM REPLY
0-5 Datagram Message Header.
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code.
0 = Stream created
8 = Network trouble
12 = Stream priority not being accepted
17 = Insufficient network resources
18 = Requested bandwidth too large
21 = Maximum messages per slot not consistent
with slot size
22 = Reply lost in network
23 = Illegal reliability value
7[0-15] Setup Checksum. Covers words 6-9.
8[0-15] Request ID.
37
RFC 907 Host Access Protocol
July 1984 Specification
9[10-15] Reserved.
9[0-9] Host Stream ID. This field contains a host stream
ID assigned by the network. It must be included in
all stream data messages sent by the host to allow
the SIMP to associate the message with stored stream
characteristics and the reserved satellite channel
time.
38
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | MAX MES | INT | PRI | RLY | RLEN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | SLOT SIZE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 12 . CHANGE STREAM PARAMETERS REQUEST
0-5 Datagram Message Header.
6[8-15] Setup Type = 1 (Request).
6[0-7] Request Type = 7 (Change Stream Parameters).
7[0-15] Setup Checksum. Covers words 6-11.
8[0-15] Request ID.
9[10-15] Reserved.
9[0-9] Host Stream ID.
10[12-15] New Maximum Messages Per Slot.
39
RFC 907 Host Access Protocol
July 1984 Specification
10[10-11] Interval. This field must specifiy the same
interval as was specified in the Create Stream
Request message for this stream.
10[8-9] New Priority.
10[6-7] New Reliability.
10[0-5] New Reliability Length.
11[0-15] New Slot Size.
40
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 13 . CHANGE STREAM PARAMETERS REPLY
0-5 Datagram Message Header.
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code.
4 = Stream changed
8 = Network trouble
10 = Stream ID nonexistent
11 = Not creator of stream
12 = Stream priority not being accepted
15 = Illegal interval
17 = Insufficient network resources
18 = Requested bandwidth too large
21 = Maximum messages per slot not consistent with
slot size
22 = Reply lost in network
23 = Illegal reliability value
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Request ID.
41
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | XXXXX | HOST STREAM ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 14 . DELETE STREAM REQUEST
0-5 Datagram Message Header.
6[8-15] Setup Type = 1 (Request).
6[0-7] Request Type = 6 (Delete Stream).
7[0-15] Setup Checksum. Covers words 6-9.
8[0-15] Request ID.
9[10-15] Reserved.
9[0-9] Host Stream ID.
42
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 15 . DELETE STREAM REPLY
0-5 Datagram Message Header.
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code.
1 = Stream deleted
8 = Network trouble
10 = Stream ID nonexistent
11 = Not creator of stream
17 = Insufficient network resources
22 = Reply lost in network
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Request ID.
43
RFC 907 Host Access Protocol
July 1984 Specification
6.2 Group Setup Messages
Group addressing allows hosts to take advantage of the
broadcast capability of the satellite network and is primarily
provided to support the multi-destination delivery required for
conferencing applications. Group addresses are dynamically
created and deleted via setup messages exchanged between hosts
and the network. Membership in a group may consist of an
arbitrary subset of all the permanent network hosts. A datagram
message or stream message addressed to a group is always sent
over the satellite channel and delivered to all hosts that are
members of that group. The group setup messages are Create Group
Request, Create Group Reply, Delete Group Request, Delete Group
Reply, Join Group Request, Join Group Reply, Leave Group Request,
and Leave Group Reply.
The use of group setup messages is shown in Figure 16. The
figure illustrates a scenario of exchanges between two hosts and
their local SIMPs. In the scenario one host, Host A, creates a
group which is joined by a second host, Host B. After the two
hosts have exchanged some data mesages addressed to the group,
Host B decides to leave the group and Host A decides to delete
the group. As in the scenario in Section 6.1, A/R indications
have been omitted for clarity.
Part of the group creation procedure involves the service
host returning a 48-bit key along with a 16-bit group address to
the host creating the group. The creating host must pass the key
along with the group address to the other hosts which it wants as
group members. These other hosts must supply the key along with
the group address in their Join Group Requests. The key is used
by the network to authenticate these operations and thereby
minimize the probability that unwanted hosts will deliberately or
inadvertently become members of the group. The procedure used by
a host to distribute the group address and key is not within the
scope of HAP.
44
RFC 907 Host Access Protocol
July 1984 Specification
Host SIMP SIMP Host
A A B B
Create Group Request ------>
Create Group Reply <------
Reply Acknowledgment ------>
.
.
>>Group Address,Key>>
.
.
Join Group Request <------
Join Group Reply ------>
Reply Acknowledgment <------
Data Message 1 ------>
Data Message 1 <------ ------>
Data Message 2 <------
Data Message 2 <------ ------>
Leave Group Request <------
Leave Group Reply ------>
Reply Acknowledgment <------
Delete Group Request ------>
Delete Group Reply <------
Reply Acknowledgment ------>
Figure 16 . GROUP EXAMPLE
Any host no longer wishing to participate in a group may
choose to drop out. This can be accomplished by either a Leave
or a Delete. Both Leave and Delete operations are authenticated
using the 48-bit key. Leave is a local operation between a host
and its SIMP which removes the requesting host from the group
membership list but does not alter the global existence of the
45
RFC 907 Host Access Protocol
July 1984 Specification
group. A Delete, on the other hand, expunges all knowledge of
the group from every SIMP in the network. HAP will permit any
member of a group to delete the group at any time. Thus, group
addresses can be deleted even if the host which originally
created the group has left the group or has crashed. Moreover,
groups may exist for which there are currently no members because
each member has executed a Leave while none has executed a
Delete. It is the responsibility of the hosts to coordinate and
manage the use of groups.
The Create Group Request message sent to the service host to
establish a group address is illustrated in Figure 17. After the
network has processed the Create Group Request, the service host
will respond by sending a Create Group Reply to the host as
illustrated in Figure 18.
A host may become a member of a group once it knows the
address and key associated with the group by sending the service
host the Join Group Request message shown in Figure 19. The
service host will respond to the Join Group Request with a Join
Group Reply formatted as indicated in Figure 20. The host which
creates a group automatically becomes a member of that group
without any need for an explicit Join Group Request.
At any time after becoming a member of a group, a host may
choose to drop out of the group. To effect this the host sends
the service host a Leave Group Request formatted as shown in
Figure 21. The service host will respond to the Leave Group
Request with a Leave Group Reply formatted as shown in Figure 22.
Any member of a group can request that the service host
delete an existing group via a Delete Group Request. The format
of the Delete Group Request setup message is illustrated in
Figure 23. After the network has processed the Delete Group
Request, the service host will respond to the host with a Delete
Group Reply formatted as illustrated in Figure 24.
46
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 1 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 17 . CREATE GROUP REQUEST
0-5 Datagram Message Header.
6[8-15] Setup Type = 1 (Request).
6[0-7] Request Type = 1 (Create Group).
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Request ID.
47
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 18 . CREATE GROUP REPLY
0-5 Datagram Message Header.
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code.
0 = Group created
8 = Network trouble
17 = Insufficient network resources
22 = Reply lost in network
7[0-15] Setup Checksum. Covers words 6-12.
8[0-15] Request ID.
48
RFC 907 Host Access Protocol
July 1984 Specification
9[0-15] Group Address. This field contains a 16-bit logical
address assigned by the network which may be used by
the host as a group address.
10-12 Key. This field contains a 48-bit key assigned by the
network which is associated with the group address.
It must be provided for subsequent Join, Leave, and
Delete requests which reference the group address.
49
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 19 . JOIN GROUP REQUEST
0-5 Datagram Message Header.
6[8-15] Setup Type = 1 (Request).
6[0-7] Request Type = 3 (Join Group).
7[0-15] Setup Checksum. Covers words 6-12.
8[0-15] Request ID.
9[0-15] Group Address. This is the logical address of the
group that the host wishes to join.
10-12 Key. This is the key associated with the group
50
RFC 907 Host Access Protocol
July 1984 Specification
address.
51
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 20 . JOIN GROUP REPLY
0-5 Datagram Message Header.
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code.
2 = Group joined
9 = Bad key
10 = Group address nonexistent
17 = Insufficient network resources
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Request ID.
52
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 21 . LEAVE GROUP REQUEST
0-5 Datagram Message Header.
6[8-15] Setup Type = 1 (Request).
6[0-7] Request Type = 4 (Leave Group).
7[0-15] Setup Checksum. Covers words 6-12.
8[0-15] Request ID.
9[0-15] Group Address. This is the logical address of the
group that the host wishes to leave.
10-12 Key. This is the key associated with the group
53
RFC 907 Host Access Protocol
July 1984 Specification
address.
54
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 22 . LEAVE GROUP REPLY
0-5 Datagram Message Header.
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code.
3 = Group left
9 = Bad key
10 = Group address nonexistent
11 = Not member of group
17 = Insufficient network resources
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Request ID.
55
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 1 | 2 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | GROUP ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
11 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
12 | KEY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 23 . DELETE GROUP REQUEST
0-5 Datagram Message Header.
6[8-15] Setup Type = 1 (Request).
6[0-7] Request Type = 2 (Delete Group).
7[0-15] Setup Checksum. Covers words 6-12.
8[0-15] Request ID.
9[0-15] Group Address.
10-12 Key.
56
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0-5 | DATAGRAM MESSAGE HEADER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | 2 | REPLY CODE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | SETUP CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | REQUEST ID |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 24 . DELETE GROUP REPLY
0-5 Datagram Message Header.
6[8-15] Setup Type = 2 (Reply).
6[0-7] Reply Code.
1 = Group deleted
8 = Network trouble
9 = Bad key
10 = Group address nonexistent
11 = Not member of group
17 = Insufficient network resources
22 = Reply lost in network
7[0-15] Setup Checksum. Covers words 6-8.
8[0-15] Request ID.
57
RFC 907 Host Access Protocol
July 1984 Specification
7 Link Monitoring
While the access link is operating, statistics on traffic
load and error rate are maintained by the host and SIMP. The
host and SIMP must exchange status messages once a second.
Periodic exchange of status messages permits both ends of the
link to monitor flows in both directions. Status messages are
required to support monitoring by the Network Operations Center
(NOC).
The link restart procedure (see Section 8) initializes all
internal SIMP counts and statistics for that link to zero. As
data and control messages are processed, counts are updated to
reflect the total number of messages sent, messages received
correctly, and messages received with different classes of errors
since the last link restart. Whenever a status message arrives,
a snapshot is taken of the local SIMP counts. The local receive
counts, in conjunction with a sent count contained in the
received status message, permits the computation of traffic
statistics in the one second update interval assuming that the
set of counts at the time of the previous monitoring report have
been saved. By including in the status message sent (in the
opposite direction) the receive counts and the received sent
count that was used with them, the transmitting end of the access
link as well as the receiving end can determine the link
performance from sender to receiver. The format of the Status
control message is illustrated in Figure 25.
58
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | 0 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | MOST RECENT A/R SENT |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | STREAM CAPACITY |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
4 | TIMESTAMP |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
5 | SBU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6 | STU |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
7 | RNE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
8 | RWE |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
9 | BHC |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
10 | HEI |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 25 . STATUS MESSAGE
0[15] Message Class = 1 (Control Message).
0[14] Loopback Bit.
0[12-13] Go-Priority.
0[4-11] Reserved.
59
RFC 907 Host Access Protocol
July 1984 Specification
0[0-3] Control Message Type = 0 (Status).
1[0-15] Header Checksum. Covers words 0-10.
2[0-15] Most Recent A/R Sent. This field is a duplicate of the
most recent acceptance/refusal word. It is included in
the periodic status message in case previous
transmissions containing A/R information were lost.
3[0-15] Stream Capacity. When sent by the SIMP, this field
indicates how much stream capacity is unused, in units
of data bits per frame. Since available capacity
depends directly on a variety of parameters that can be
selected by the user, the value of this field is the
maximum capacity that could be achieved if existing
host streams were expanded at low reliability. This
field is undefined in messages sent from the host to
the SIMP.
4[0-15] Timestamp. This field indicates the time that the
status message was generated. When sent by a SIMP, the
time is in units of seconds since the last link
restart. The host should also timestamp its messages
in units of seconds.
5[0-15] Sent By Us. Count of messages sent by us since the last
link restart (not including this one).
6[0-15] Sent To Us. Count of messages sent to us since the
last link restart. This is the count from word 5 of
the last status message received.
7[0-15] Received, No Errors. This is the count of messages
received without errors (since the last link restart)
at the time that the last status message was received.
8[0-15] Received With Errors. This is the count of messages
received with errors (since the last link restart) at
the time the last status message was received.
9[0-15] Bad Header Checksums. This is the count of messages
60
RFC 907 Host Access Protocol
July 1984 Specification
received with bad header checksums (since the last link
restart) at the time the last status message was
received.
10[0-15] Hardware Error Indication. This is the count of
messages received with hardware CRC errors or hardware
interface error indications (since the last link
restart) at the time the last status message was
received.
61
RFC 907 Host Access Protocol
July 1984 Specification
8 Initialization
The Host Access Protocol uses a number of state variables
that must be initialized in order to function properly. These
variables are associated with the send and receive message
numbers used by the acceptance/refusal mechanism and the
statistics maintained to support link monitoring. Link
initialization should be carried out when a machine is initially
powered up, when it does a system restart, when the ON state (see
below) times out, when a loopback condition times out (see
Section 9), or whenever the link transitions from non-operational
to operational status.
Initialization is accomplished by the exchange of Restart
Request (RR) and Restart Complete (RC) messages between a host
and a SIMP. The state diagram in Figure 26 shows the sequence of
events during initialization. Both SIMP and host must implement
this state diagram if deadlocks and oscillations are to be
avoided. This particular initialization sequence requires both
sides to send and receive the Restart Complete message. Because
this message is a reply (to a Restart Request or Restart
Complete), its receipt guarantees that the physical link is
operating in both directions. Five states are identified in the
state diagram:
OFF Entered upon recognition of a requirement to
restart. The device can recognize this
requirement itself or be forced to restart by
receipt of an RR message from the other end while
in the ON state.
INIT Local state variables have been initialized and
local counters have been zeroed but no restart
control messages have yet been sent or received.
RR-SNT A request to reinitialize (RR) has been sent to
the other end but no restart control messages have
yet been received.
RC-SNT A reply (RC) has been sent to the other end in
response to a received reinitialization request
62
RFC 907 Host Access Protocol
July 1984 Specification
(RR). The device is waiting for a reply (RC).
ON Reply (RC) messages have been both sent and
received. Data and control messages can now be
exchanged between the SIMP and host.
All states have 10-second timeouts (not illustrated) which
return the protocol to the OFF state. The occurrence of any
events other than those indicated in the diagram are ignored.
The Restart Request control message illustrated in Figure 27
is sent by either a host or a SIMP when it wishes to restart a
link. The Restart Request causes all the monitoring statistics
to be reset to zero and stops all traffic on the link in both
directions. The Restart Complete message illustrated in Figure
28 is sent in response to a received Restart Request or Restart
Complete to complete link initialization. The Restart Complete
carries a field used by the host to enable or disable the
acceptance/refusal mechanism for the link being restarted (see
Section 5). After the Restart Complete is processed, traffic may
flow on the link.
63
RFC 907 Host Access Protocol
July 1984 Specification
-------
Any Timeout or ----->| OFF |<-----------------------------
Device Down ------- |
| |
| Device Up |
| Initialize Variables |
| |
V |
--------- |
| INIT | |
--------- |
| | |
Rcv RR | | Snd RR |
Snd RC | | |
| | |
-------------- -------------- |
| | |
| | |
V Rcv RR V |
---------- Snd RC ---------- |
| RC-SNT |<--------------------| RR-SNT | |
---------- ---------- |
| | |
Rcv RC | | Rcv RC |
| | Snd RC |
V V |
------------------------------- |
| |
| |
V |
------- |
Rcv Any ------>| ON |------------------------------
Other | ------- Rcv RR
----------|
Figure 26 . HAP LINK RESTART STATE DIAGRAM
64
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXXXX | REASON | 3 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS / SITE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 27 . RESTART REQUEST
0[15] Message Type = 1 (Control Message).
0[14] Loopback Bit.
0[8-13] Reserved.
0[4-7] Reason. This field is used by the SIMP or the host to
indicate the reason for the restart as follows:
0 = power up
1 = system restart
2 = link restart
3 = link timeout
4 = loopback timeout
0[0-3] Control Message Type = 3 (Restart Request).
1[0-15] Header Checksum. Covers words 0-3.
2[0-15] Host Address / Site Number. The host inserts its
satellite network address in this field. The SIMP
validates that the host address is correct for the port
65
RFC 907 Host Access Protocol
July 1984 Specification
being used. When sent by the SIMP, this field will
contain the SIMP site number.
3[0-15] Link Number. This field contains the sender's
identification of the physical link being used. This
information is used to identify the link when reporting
errors to the Network Operations Center (NOC).
66
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXXX |AR| 4 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | HOST ADDRESS / SITE NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | LINK NUMBER |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 28 . RESTART COMPLETE
0[15] Message Type = 1 (Control Message).
0[14] Loopback Bit.
0[5-13] Reserved.
0[4] Acceptance/Refusal Control. This bit is used by the
host to enable or disable the acceptance/refusal
mechanism for all traffic on the link.
0 = Disable acceptance/refusal
1 = Enable acceptance/refusal
0[0-3] Control Message Type = 4 (Restart Complete).
1[0-15] Header Checksum. Covers words 0-3.
2[0-15] Host Address / Site Number.
3[0-15] Link Number.
67
RFC 907 Host Access Protocol
July 1984 Specification
9 Loopback Control
The Host Access Protocol provides a Loopback Request control
message which can be used by a SIMP or a host to request the
remote loopback of its HAP messages. Such requests are usually
the result of operator intervention for purposes of system fault
diagnosis. For clarity in the following discussion, the unit
(SIMP or host) requesting the remote loopback is referred to as
the "transmitter" and the unit implementing (or rejecting) the
loopback is referred to as the "receiver". The format of a
Loopback Request control message is illustrated in Figure 29.
When a transmitter is remotely looped, all of its HAP
messages will be returned, unmodified, over the access link by
the receiver. The receiver will not send any of its own messages
to the transmitter while it is implementing the loop. SIMP-
generated messages are distinguished from host-generated messages
by means of the Loopback Bit that is in every HAP message header.
Two types of remote loopback may be requested: loopback at
the receiver's interface hardware and loopback at the receiver's
I/O driver software. HAP does not specify the manner in which
the receiver should implement these loops; additionally, some
receivers may use interface hardware which is incapable of
looping the transmitter's messages, only allowing the receiver to
provide software loops. A receiver may not be able to interpret
the transmitter's messages as it is looping them back. If such
interpretation is possible, however, the receiver will not act on
any of the transmitter's messages other than requests to
reinitialize the SIMP-host link (Restart Request (RR) control
messages; see Section 8.)
When a receiver initiates a loopback condition in response
to a loopback request, it makes an implicit promise to maintain
the condition for the duration specified in the Loopback Request
message. However, if an unanticipated condition such as a system
restart occurs in either the transmitter or the receiver, the
affected unit will try to reinitialize the SIMP-host link by
sending an RR message to the other unit. If the RR message is
recognized by the other unit a link initialization sequence can
be completed. This will restore the link to an unlooped
68
RFC 907 Host Access Protocol
July 1984 Specification
condition even if the specified loop duration has not yet
expired. If a receiver cannot interpret a transmitter's RR
messages, and in the absence of operator intervention at the
receiver, the loop will remain in place for its duration.
HAP does not specify the characteristics of any loopback
conditions that may be locally implemented by a given unit. An
example of such a condition is that obtained when a SIMP commands
its host interface to loop back its own messages. If such local
loop conditions also cause the reflection of messages received
from the remote unit, the remote unit will detect the condition
via the HAP header Loopback Bit.
A specific sequence must be followed for setting up a remote
loopback condition. It begins after the HAP link has been
initialized and a decision is made to request a remote loop. The
transmitter then sends a Loopback Request message to the receiver
and waits for either (1) a 10-second timer to expire, (2) a
"Can't implement loop" Unnumbered Response message from the
receiver, or (3) one of its own reflected messages. If event (1)
or (2) occurs the request has failed and the transmitter may, at
its option, try again with a new Loopback Request message. If
event (3) occurs, the remote loopback condition has been
established. While waiting for one of these events, messages
from the receiver are processed normally. Note that RR messages
arriving from the receiver during this time will terminate the
loopback request.
When a receiver gets a Loopback Request message, it either
implements the requested loop for the specified duration, or
returns a "Can't implement loop" response without changing the
state of the link. The latter response would be returned, for
example, if a receiver is incapable of implementing a requested
hardware loop. A receiver should initiate reinitialization of
the link with an RR message(s) whenever a loopback condition
times out.
There is one asymmetry that is required in the above
sequence to resolve the (unlikely) case where both SIMP and host
request a remote loopback at the same time. If a SIMP receives a
Loopback Request message from a host while it is itself waiting
69
RFC 907 Host Access Protocol
July 1984 Specification
for an event of type (1)-(3), it will return a "Can't implement
loop" response to the host and will continue to wait. A host in
the converse situation, however, will abort its loopback request
and will instead act on the SIMP's loopback request.
70
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | LOOP TYPE | 8 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | LOOP DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 29 . LOOPBACK REQUEST
0[15] Message Type = 1 (Control Message).
0[14] Loopback Bit.
0[12-13] Go-Priority.
0[8-11] Reserved.
0[4-7] Loop Type. This field indicates the type of loop that
is being requested as follows:
0 = Undefined
1 = Loop at interface (hardware loop)
2 = Loop at driver (software loop)
3-15 = Undefined
0[0-3] Control Message Type = 8 (Loopback Request).
1[0-15] Header Checksum. Covers words 0-2.
2[0-15] Loop Duration. The transmitter of a Loopback
Request message uses this field to specify the number
of seconds that the loop is to be maintained by the
receiver.
71
RFC 907 Host Access Protocol
July 1984 Specification
10 Other Control Messages
Before a SIMP or a host voluntarily disables a SIMP-host
link, it should send at least one Link Going Down control message
over that link. The format of such a message is illustrated in
Figure 30. HAP does not define the action(s) that should be
taken by a SIMP or a host when such a message is received;
informing the Network Operations Center (NOC) and/or the network
users of the impending event is a typical course of action. Note
that each Link Going Down message only pertains to the SIMP-host
link that it is sent over; if a host and a SIMP are connected by
multiple links, these links may be selectively disabled.
A No Operation (NOP) control message may be sent at any time
by a SIMP or a host. The format of such a message is illustrated
in Figure 31. A NOP message contains up to 32 words of arbitrary
data which are undefined by HAP. NOP messages may be required in
some cases to clear the state of the SIMP-host link hardware.
72
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB|GOPRI| XXXXX | REASON | 7 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2 | TIME UNTIL DOWN |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
3 | DOWN DURATION |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 30 . LINK GOING DOWN
0[15] Message Type = 1 (Control Message).
0[14] Loopback Bit.
0[12-13] Go-Priority.
0[8-11] Reserved.
0[4-7] Reason. This field is used by the SIMP or the host
to indicate the reason for disabling this SIMP-host
link as follows:
0 = NOT going down: Cancel previous Link
Going Down message
1 = Unspecified reason
2 = Scheduled PM
3 = Scheduled hardware work
4 = Scheduled software work
5 = Emergency restart
6 = Power outage
7 = Software breakpoint
8 = Hardware failure
73
RFC 907 Host Access Protocol
July 1984 Specification
9 = Not scheduled up
10 = Last warning: The SIMP or host is disabling
the link in 10 seconds
11-15 = Undefined
0[0-3] Control Message Type = 7 (Link Going Down).
1[0-15] Header Checksum. Covers words 0-3.
2[0-15] Time Until Down. This field specifies the amount of
time remaining until the SIMP or host disables the
link (in minutes). An entry of zero indicates that
there is less than a minute remaining.
3[0-15] Down Duration. This field specifies the amount of
time that the SIMP-host link will be down (in
minutes). An entry of zero indicates that the down
duration will be less than a minute. An entry of -1
(all bits set) indicates an indefinite down duration.
74
RFC 907 Host Access Protocol
July 1984 Specification
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 | 1|LB| XXXXX | 6 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
1 | HEADER CHECKSUM |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
2-N | ARBITRARY DATA |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 31 . NO OPERATION (NOP)
0[15] Message Type = 1 (Control Message).
0[14] Loopback Bit.
0[4-13] Reserved.
0[0-3] Control Message Type = 6 (NOP).
1[0-15] Header Checksum. Covers words 0-N.
2-N Arbitrary Data. Up to 32 words of data may be sent.
The data are undefined by HAP.
75
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/
